expose transform and resolveapi from parcel

[kiddkai]

↪️ Pull Request

Exposes two new API to public use:

• Parcel.transform
• Parcel.resolve

So API consumers can use these two features to reuse the same resolve & transform pipelines
during development.

The implementation is mostly a copy of: v2...parcel-node

But it excluded the features specifically for jest and NodeResolve.
And it does not transform import directly to require that only specific for node register.
As an alternative, we may be able to add another asset query to change it to something else.

eg:

query: `standalone=true&renameImportTo=__custom__import__`

Which provides more customisability, but I am not adding it for now since we still able to post-process the import() for now.

💻 Examples

The new exposed API allows us to do:

let parcel = createParcel({workerFarm});
    let res = await parcel.transform({
      filePath: path.join(__dirname, 'fixtures/parcel/other.js'),
      query: 'standalone=true',
    });
    let code = await res[0].getCode();

    assert(code.includes('require("./index.js")'));
    assert(code.includes('new URL("index.js", "file:" + __filename);'));
    assert(code.includes('import("index.js")'));

And

let res = await parcel.resolve({
        specifier: './other',
        specifierType: 'esm',
        resolveFrom: path.join(__dirname, 'fixtures/parcel/index.js'),
      });
      assert.deepEqual(res, {
        filePath: path.join(__dirname, 'fixtures/parcel/other.js'),
        code: undefined,
        query: undefined,
        sideEffects: undefined,
      });

which allows us to develop custom runtime based on v8 or similar js runtime to share the
transform and resolve pipelines during development without bundling the whole project
which benefits huge projects that takes long time to bundle.

🚨 Test instructions

• Unit tested.

✔️ PR Todo

• Added/updated unit tests for this change
• Filled out test instructions (In case there aren't any unit tests)
• Included links to related issues/PRs

[mattcompiles]

Couple of questions but this is looking pretty good and love how simple it is to add so far.

@devongovett Would love your thoughts on the comments as well.

[mattcompiles]

Should we use force here? My understanding is that force means the cache is ignored.

[kiddkai]

I can update that, but it was originally copied from the intiial branch, I will leave this Q to @devongovett on if this is required?

[kiddkai]

Just changed it to a configurable value. Follows the config of shouldCacheDisabled from the main config.
I guess this could be helpful to debug transform problems.

[mattcompiles]

Same question here about force.

[mattcompiles]

Not sure what the purpose of this name is. Looks like it's normally sourced from the AssetGraphBuilder and it could be Main or Runtimes.

@devongovett Any input on what this should be?

[kiddkai]

I changed it to .specifeir

The name seem to be used to construct the req.id only. The first part of id is already hashed, so whatever value here doesn't seem to be matter too much.

Tho, change to specifier should be a lil bit more meaningful.

[mattcompiles]

Not sure if pipeline makes sense as a public option? Shouldn't this be inferred from the .parcelrc?

[kiddkai]

I am happy to remove this pipline property.

[kiddkai]

removed.

[mattcompiles]

Not sure about using a query param to drive this behaviour. Maybe this should be part of the environment?

[kiddkai]

I did think about it, for now using query provides some flexibility & less moving part to change the environment. Kinda like a feature flag for jsTransform for now.

[mattcompiles]

As above

[kiddkai]

updated.

[mattcompiles]

Turns out I was wrong about this and there's a separate cache layer for transforms so this is safe to hardcode as true.

[kiddkai]

updated