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 a non-minified file in the distribution on npm #69

Closed
atimmer opened this issue Jan 28, 2019 · 6 comments
Closed

Add a non-minified file in the distribution on npm #69

atimmer opened this issue Jan 28, 2019 · 6 comments

Comments

@atimmer
Copy link

atimmer commented Jan 28, 2019

In WordPress we include the FormData polyfill. We also want to ship a non-minified version. This is because when the PHP constant SCRIPT_DEBUG is enabled we use the non-minified versions of all scripts so users can inspect and debug these scripts.

Would it be possible to ship a non-minified file in the npm distribution?

Relevant issue in WordPress: https://core.trac.wordpress.org/ticket/46110

@jimmywarting
Copy link
Owner

hmm,
Using whitespace with closure-compiler is not a solution since it will not transpile es6 down to old syntax. But i saw a option for pretty print...

Would a source map be a solution also?

@jaydenseric
Copy link

It is best practice not to ship minified (or bundled) code to npm; that is best performed by the consumer in their project.

I suggest removing the build script and minified file. If the source needs to be transpiled, you can use Babel dev dependencies and setup a prepare package script. That way users can install this package as a git dependency to try out forks/PRs, etc.

@jimmywarting
Copy link
Owner

jimmywarting commented Feb 12, 2019

It is best practice not to ship minified (or bundled) code to npm; that is best performed by the consumer in their project.

I did that before, it ended up with ppl complaining that the polyfill didn't work in there build step - they might just have used a simple gulp script to concatenate all files without babel or something like it

I suggest removing the build script and minified file. If the source needs to be transpiled, you can use Babel dev dependencies and setup a prepare package script. That way users can install this package as a git dependency to try out forks/PRs, etc.

I'm not keen to switch to using another compiler. and ppl are probably already hot linking to github using jsdelivr so i'm not removing the minified file either - and i will keep updating the minified file for future references


if you don't want to use the minifed version you could always include the es6 version right await
require('formdata-polyfill/FormData.js')


Another idea maybe is to change the code to be written with es5 instead - thoughts?

@jaydenseric
Copy link

jaydenseric commented Feb 12, 2019

I did that before, it ended up with ppl complaining that the polyfill didn't work in there build step - they might just have used a simple gulp script to concatenate all files without babel or something like it

It sounds like you were publishing untranspiled source code. You should publish transpiled code, just don't minify (or bundle) it.

The generally accepted standard for published code used to be ES5. But best practice today is to establish a browserslist query, and let @babel/preset-env transpile the source code to your chosen level of browser support. Personally I use > 0.5%, not dead, node 6:

https://github.com/jaydenseric/extract-files/blob/v5.0.1/package.json#L35

Something else good to do is to publish native ESM in sibling .mjs files. You do all the the other transpilations except you retain the ESM syntax:

https://github.com/jaydenseric/extract-files/blob/v5.0.1/package.json#L60
https://github.com/jaydenseric/extract-files/blob/v5.0.1/babel.config.js#L7

@jimmywarting
Copy link
Owner

It sounds like you were publishing untranspiled source code. You should publish transpiled code, just don't minify (or bundle) it.

Correct - Personally I rather have a sourcemap that points to the actual part of the code rather then to some place in the transpiled place

@stale stale bot added the wontfix label Mar 14, 2019
@stale stale bot closed this as completed Mar 21, 2019
@jimmywarting jimmywarting reopened this Mar 21, 2019
@stale stale bot removed the wontfix label Mar 21, 2019
@stale stale bot added the wontfix label Apr 25, 2019
Repository owner deleted a comment from stale bot Apr 25, 2019
@stale stale bot removed the wontfix label Apr 25, 2019
Repository owner deleted a comment from stale bot Apr 25, 2019
Repository owner deleted a comment from afercia Apr 25, 2019
@stale
Copy link

stale bot commented May 25, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label May 25, 2019
@stale stale bot closed this as completed Jun 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants