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

Build: Improve setup of package.json files #15879

Merged
merged 2 commits into from Jun 3, 2019

Conversation

@gziolo
Copy link
Member

commented May 29, 2019

Description

An alternative to #15841 where I tried:

This allows us to use a more predictable way to filter out packages which don't need to be processed with Babel. It will also make it possible to use src subfolder in packages which don't need to transpiled.

It turned out that we can't use implementation based on new type field:

I can confirm based on http://2ality.com/2019/04/nodejs-esm-impl.html#filename-extensions that commonjs is the default type. This makes this proposal not viable. I figured out that we can reason about the package type based on the “module” field. Only those transpiled with Babel have this field defined. I will open another PR where I will move some of the logic which this PR adds.

This PR use module field to achieve the same goal.

In addition, it does some chores:

  • adds files, main and react-native fields where applicable
  • enforces order for react-native and type fields if defined in package.json file

How has this been tested?

npm run lint & npm run build

I also confirmed that only packages which use Babel are listed in those which are built with npm run build:packages.

@hypest

hypest approved these changes May 29, 2019

Copy link
Contributor

left a comment

Looks good from native mobile's point of view 👍 .

Show resolved Hide resolved packages/npm-package-json-lint-config/CHANGELOG.md
Show resolved Hide resolved packages/library-export-default-webpack-plugin/package.json
Show resolved Hide resolved packages/eslint-plugin/package.json Outdated
@@ -21,6 +21,7 @@
},
"files": [
"arrays.js",
"index.js",

This comment has been minimized.

Copy link
@aduth

aduth May 29, 2019

Member

Is this module totally broken from NPM ? This seems like it would be necessary for it to work 😯

Sometimes I wonder if it's worthwhile to use a files whitelist, vs. the (apparently real) risk of neglecting to include files.

Edit:

At least on unpkg, it seems to be intact? https://unpkg.com/@wordpress/is-shallow-equal@1.3.0/index.js

How does that work?

There are some always-included files, but index.js is not one of them:

https://docs.npmjs.com/files/package.json#files

And I don't think we'd want to cherry-pick individual "always included"; either consistently assume the inherited always-included, or consistently list them all explicitly.

This comment has been minimized.

Copy link
@koke

koke May 30, 2019

Contributor

There are some always-included files, but index.js is not one of them:

https://docs.npmjs.com/files/package.json#files

It is included, not because of the name, but because it's the file in the “main” field.

This comment has been minimized.

Copy link
@gziolo

gziolo May 30, 2019

Author Member

Certain files are always included, regardless of settings:

  • package.json
  • README
  • CHANGES / CHANGELOG / HISTORY
  • LICENSE / LICENCE
  • NOTICE
  • The file in the “main” field

I can remove all files listed in main. I assumed it can be confusing for those who don't know how it exactly works and it's better to whitelist all code related files. I'd be also fine with using lib folder for those packages which use CommonJS syntax.

This comment has been minimized.

Copy link
@aduth

aduth May 30, 2019

Member

There are some always-included files, but index.js is not one of them:
https://docs.npmjs.com/files/package.json#files

It is included, not because of the name, but because it's the file in the “main” field.

Ah! I searched the page for the literal term "index", and admittedly did not read the list in detail this time around 😅 That makes sense now.

I'm on the fence about whether we include it, or allow it to be implied from main, or include it and avoid main, or include all implicit files. I agree it can be confusing for those unfamiliar with the default files (me, apparently 😆). Since generally I'm expecting these to be "the files required for runtime execution", seems reasonable to expect index.js here.

This comment has been minimized.

Copy link
@gziolo

gziolo May 30, 2019

Author Member

Yes, I'm fine with whatever people prefer here. I can keep it as is, remove main from files. Both work for me.

This comment has been minimized.

Copy link
@gziolo

gziolo Jun 3, 2019

Author Member

I merged this PR, we can revisit this later :)

This comment has been minimized.

Copy link
@aduth

aduth Jun 3, 2019

Member

I merged this PR, we can revisit this later :)

Yeah, I'm not really sure what the best option is, since they all seem to have some downside. It's fine enough to move forward with.

@gziolo gziolo force-pushed the update/module-package-json branch from f56ef5e to 8b48a13 May 30, 2019

@gziolo gziolo added this to the 5.9 (Gutenberg) milestone May 30, 2019

@gziolo gziolo merged commit dbc155c into master Jun 3, 2019

1 check passed

Travis CI - Pull Request Build Passed
Details

@gziolo gziolo deleted the update/module-package-json branch Jun 3, 2019

nicolad added a commit to nicolad/gutenberg that referenced this pull request Jun 15, 2019

Build: Improve setup of package.json files (WordPress#15879)
* Build: Improve setup of package.json files

* Address feedback from reviews

jg314 added a commit to jg314/gutenberg that referenced this pull request Jul 19, 2019

Build: Improve setup of package.json files (WordPress#15879)
* Build: Improve setup of package.json files

* Address feedback from reviews
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.