Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add esm format alias #2102

Merged
merged 4 commits into from
Apr 17, 2018
Merged

Add esm format alias #2102

merged 4 commits into from
Apr 17, 2018

Conversation

TrySound
Copy link
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?

Copy link
Contributor

@guybedford guybedford left a comment

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.

@@ -229,7 +229,7 @@ function checkOutputOptions(options: OutputOptions) {

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
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
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?

@@ -229,7 +229,7 @@ function checkOutputOptions(options: OutputOptions) {

if (!options.format) {
Copy link
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
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
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
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.

src/Chunk.ts Outdated
@@ -403,10 +403,10 @@ export default class Chunk {
}

private prepareDynamicImports({ format }: OutputOptions) {
const es = format === 'es';
const esm = format === 'esm' || format === 'es';
Copy link
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
Member Author

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

@Rich-Harris
Copy link
Contributor

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

@TrySound
Copy link
Member Author

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

@lukastaegert
Copy link
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
Member Author

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

Copy link
Contributor

@guybedford guybedford left a comment

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.

@@ -6,7 +6,7 @@ const { extend, loadConfig, normaliseOutput } = require('../utils.js');

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
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
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
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.

@@ -7,7 +7,7 @@ const { extend, loadConfig } = require('../utils.js');

const samples = path.resolve(__dirname, 'samples');

const FORMATS = ['es', 'cjs', 'amd', 'system'];
const FORMATS = ['es', 'esm', 'cjs', 'amd', 'system'];
Copy link
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
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

@@ -229,7 +229,7 @@ function checkOutputOptions(options: OutputOptions) {

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
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
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
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
Member Author

Done

@guybedford
Copy link
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
Copy link

stefanocke commented Jul 14, 2019

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
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

@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.

None yet

5 participants