Give all plugins access to config

[101arrowz]

🙋 feature request

Give every plugin type access to a config object (options for the plugin itself) in Parcel v2. The plugin configuration will be found and parsed by Parcel in either package.json or in .parcelrc.

🔦 Context

My plugin for Parcel v1 needed access to configuration to function. In Parcel v1, getting config meant either reading directly from the filesystem or reading from package.json using entryAsset.getPackage(). Not only is this bad practice, it can be managed better in Parcel v2 with the existence of the .parcelrc file.

💻 Examples

In .parcelrc:

{
    "runtimes": [
        "parcel-runtime-thing",
        ["parcel-runtime-with-config", {
            "my": "configuration",
            "is": { "right": "here" },
            "any": [
                 "json object is supported",
                  1234
            ]
        }]
    ]
}

In addition to the other parameters provided to the bundle method, parcel-runtime-with-config will receive a config key with the same value as the second element in the above tuple. On the other hand, parcel-runtime-thing, will receive null for config.

[DeMoorJasper]

either reading directly from the filesystem or reading from package.json using entryAsset.getPackage(). Not only is this bad practice

How is this bad practice? I would argue the other way around is bad practice, due to the spread of config in tooling specific config files like parcelrc or webpack.config.js or whatever you lose the ability to re-use configs across bundlers and other tools like tests, ...

For this you should probably add a key to pkg.json or an additional file like you stated it should not have any significant performance impact and we're gonna look into optimising this regardless anyway.

We have good reasons for not allowing this and I doubt this will change.

[101arrowz]

So you're suggesting that plugins read config directly from the filesystem with a .pluginnamerc file such that they can work when people migrate to other build tools? The only reason I suggested this is that config discovery can fail if the CWD is different from the project root.

[DeMoorJasper]

Why would config not be in the projectRoot, parcelrc is also in the project root so that wouldn't make a difference

[101arrowz]

No, I mean the current working directory. i.e. parcel build in a subdirectory.

[devongovett]

I wouldn't suggest reading directly from the filesystem but rather using Parcel's config loading APIs. This will ensure that Parcel invalidates the cache when the config file changes properly.

[101arrowz]

Also, a secondary reason for suggesting this is that there is no watch support when having a manual config file. Maybe a method to register a file to be watched could be useful, so it can rerun the plugin when the config file changes.

[mischnic]

Maybe a method to register a file to be watched could be useful

That already exists:

parcel/packages/transformers/sass/src/SassTransformer.js

Lines 41 to 43 in d33fcd9

	let config = await asset.getConfig(['.sassrc', '.sassrc.js'], {
	packageKey: 'sass',
	});

[101arrowz]

Alright, thanks for the help. Forgive me for not looking into this myself; hopefully documentation for the new plugin API will come soon!

[DeMoorJasper]

Ow that was the real issue.

@mischnic however shared the old and deprecated API as an example. Probably better to look at the new API which adds additional methods to transformer for cache control and hydrating configs so we always have a static config file to cache.

https://github.com/parcel-bundler/parcel/blob/v2/packages/transformers/postcss/src/PostCSSTransformer.js#L19-L30

[101arrowz]

That new API seems to only exist for transformer plugins; is there a way to get similar functionality (i.e. that config.getConfig() method) for other plugins?

[mischnic]

That is planned but not yet implemented.

[tonyhallett]

From the types https://github.com/parcel-bundler/parcel/blob/v2/packages/core/types/index.js

Transformer
Bundler
Namer
Runtime
Packager
Optimizer