Skip to content

Add esm format alias - #2102

Merged
guybedford merged 4 commits into
masterfrom
esm-format-alias
Apr 17, 2018
Merged

Add esm format alias#2102
guybedford merged 4 commits into
masterfrom
esm-format-alias

Conversation

@TrySound

Copy link
Copy Markdown
Member

Ref #1917

Added esm as an alias to be compatible in naming with esm loader.

Also since it's more descriptive renamed a few variables too.

Should I add format for every form in tests?

@guybedford guybedford left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for getting to this, have been meaning to myself.

I guess we should decide if we want to make esm the main form and deprecate es or just allow it as an alias.

Perhaps just treating it as an alias for now, to avoid documentation changes etc might be simpler, but I'm open to considering the more major deprecation path - although will likely need further feedback from @Rich-Harris and @lukastaegert on this.

Comment thread src/rollup/index.ts
if (!options.format) {
error({
message: `You must specify options.format, which can be one of 'amd', 'cjs', 'system', 'es', 'iife' or 'umd'`,
message: `You must specify options.format, which can be one of 'amd', 'cjs', 'system', 'esm', 'iife' or 'umd'`,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do this, we should work on a documentation change as well.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although for now, I'm thinking it might just be better to treat esm as an alias, with es remaining the primary term - moving to consider this being changed in future?

Comment thread src/rollup/index.ts
@@ -229,7 +229,7 @@ function checkOutputOptions(options: OutputOptions) {

if (!options.format) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An alternative here might be to do if (options.format === 'es') options.format = 'esm'; to avoid the need to do both checks through the codebase.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this merge should happen in mergeOptions?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could work, but there is an issue, what we should pass to transformBundle(code, { format })?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be a breaking change to alter - so keeping es internally and esm as an alias is probably the best bet.

Comment thread src/Chunk.ts Outdated

private prepareDynamicImports({ format }: OutputOptions) {
const es = format === 'es';
const esm = format === 'esm' || format === 'es';

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally all these checks should only check one format string - either esm or es, with internal rewriting to ensure only one is used.

@TrySound

Copy link
Copy Markdown
Member Author

Added tests for esm with a couple of hacks to reuse es expected

@Rich-Harris

Copy link
Copy Markdown
Contributor

I'd be pro-deprecating es in favour of esm. I think it's much more descriptive for most people

@TrySound

Copy link
Copy Markdown
Member Author

We can then merge this pr with an alias to give users time to migrate then add deprecation.

@lukastaegert

Copy link
Copy Markdown
Member

I would prefer esm over es as well but I do not see a safe way to change that without potentially breaking important plugins. This not only affects the transformBundle hook but also the ongenerate and onwrite hooks and will require careful communication from our side that important plugins need to match both aliases before we can do the change. Not sure which plugins are actually affected, though.

@TrySound

Copy link
Copy Markdown
Member Author

I can coordinate this breaking change through all of these modules.

@guybedford guybedford left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me, just a question re possible duplication in the tests.

Comment thread test/form/index.js Outdated
const samples = path.resolve(__dirname, 'samples');

const FORMATS = ['amd', 'cjs', 'system', 'es', 'iife', 'umd'];
const FORMATS = ['amd', 'cjs', 'system', 'es', 'esm', 'iife', 'umd'];

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean to include both es and esm here or just use esm?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both. Esm is an alias which we also should test

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but it will slow down the tests if we're rerunning each and every es module format test twice now. Perhaps just one test is necessary.

Comment thread test/chunking-form/index.js Outdated
const samples = path.resolve(__dirname, 'samples');

const FORMATS = ['es', 'cjs', 'amd', 'system'];
const FORMATS = ['es', 'esm', 'cjs', 'amd', 'system'];

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove 'es' case?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are gonna support both for now

Comment thread src/rollup/index.ts Outdated
if (!options.format) {
error({
message: `You must specify options.format, which can be one of 'amd', 'cjs', 'system', 'es', 'iife' or 'umd'`,
message: `You must specify options.format, which can be one of 'amd', 'cjs', 'system', 'esm', 'es', 'iife' or 'umd'`,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we already move to only documenting esm perhaps as a first step towards deprecation?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably

@guybedford

Copy link
Copy Markdown
Contributor

Could you rebase this for merge? Otherwise I can aim to take a look.

Sorry this one dropped off my radar, would be great to get it in.

@TrySound

Copy link
Copy Markdown
Member Author

Done

@guybedford

Copy link
Copy Markdown
Contributor

Amazing, thanks for the update here.

We should be able to switch around the es and esm internally on a future major, deprecating the es input from there. Perhaps a 1.0 goal if we get that milestone going soon!

@stefanocke

stefanocke commented Jul 14, 2019

Copy link
Copy Markdown

The generateBundle hook in rollup version 1.16 still gives me "es" instead of "esm" in outputOptions.format. In my rollup config, I have "esm".

Does this mean, the breaking change did not happen in 1.x?
Is it planned for future majos releases?

@TrySound

Copy link
Copy Markdown
Member Author

@stefanocke Yes, breaking change did not happen before 1.0. esm is only alias for now. We may reconsider this later.

@stefanocke

Copy link
Copy Markdown

@TrySound , thanks for clarification.

EliasHasle added a commit to EliasHasle/three.js that referenced this pull request Jul 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants