5 ms·

> I don't know how to publish this package in a way all JS transpilers and bundlers out there can understand. Please help me. Don't do this: module.export

by DiThi 9y ago

> I don't know how to publish this package in a way all JS transpilers and bundlers out there can understand. Please help me. Don't do this: module.exports = IPFSDropzone Do this (and change documentation accordingly) module.exports = {IPFSDropzone} or to go full ES6 do this export {IPFSDropzone}; add the package babel-env and add this script to package.json: "scripts": { "prepublish": "node node_modules/babel-cli/bin/babel *.js -d build/" }, and change main to "build/index.js". Run "npm run prepublish" to test. Edit: Now that I think of it, compiling with babel is probably unnecessary. But it doesn't hurt and can help old setups.

SEJeff 9y ago
Why not send a PR?
- toddmatthews 9y ago
  teach a man to fish
  - mhluongo 9y ago
    ... the PR would do that as well
    - bringtheaction 9y ago
      Not necessarily. PR on GitHub can be merged with the push of a button so it's more likely to be looked at only cursory before getting merged and therefore will be forgotten whereas when the author needs to retype it they will have a stronger memory of it and they remember where to go back and look next time
  - hinkley 9y ago
    Give a man a fire, he's warm for a day. Set a man on fire, and he's warm for the rest of his life.
    - hetspookjee 9y ago
      This is brilliant.
      - hinkley 9y ago
        Terry Pratchett, RIP.
- DiThi 9y ago
  For other people in the comments that may have a similar problem.
- igorgue 9y ago
  AFAIK there's no upvotes on github ;-)
- hinkley 9y ago
  "The problem with doing something right the first time is nobody appreciates how hard it was."
allover 9y ago
> Don't do this: > module.exports = IPFSDropzone > Do this (and change documentation accordingly) > module.exports = {IPFSDropzone} Why? Exporting a single class for this kind of lib is preferable. I'd do: export default IPFSDropzone; See react-dropzone which does this [1]. (For that matter the author's questions around project setup would probably be answered by looking at react-dropzone's which looks pretty good). Also with npm scripts, local deps that expose executables are added to your PATH so you can call them directly, e.g. "prepublish": "babel *.js -d build/" [1] https://github.com/react-dropzone/react-dropzone/blob/master/src/index.js#L415 https://github.com/react-dropzone/react-dropzone/blob/master...
- DiThi 9y ago
  Because having a mix of libraries/modules which some export defaults and some don't makes it cumbersome to require them here and there: I have to remember which was exported as default and which had the class inside. Also it makes more obvious visually which variables are modules and which are classes/functions. For my projects I avoid default exports even when a module only has one class (which happens frequently). Additionally, ES6 default exports don't mix well with commonJS, sometimes I have to add require('foo').default for no apparent reason. > Also with npm scripts, local deps that expose executables are added to your PATH I think it didn't work reliably on windows or cygwin or something. I just tried and it works everywhere. Good to know! The only gotcha is that ";" and "&&" must have spaces around.
fiatjaf 9y ago
Thank you. But here are my concerns: * If I go ES6 I'll require all people importing it to also use an ES6 module bundler -- which means Babel only, or Rollup, which never works. * If I precompile and expect non-Babel people to use the precompiled then these people will have duplicated dependencies everywhere. Not complaining, but all this compatibility mess seems hard to me. I use Browserify!
- DiThi 9y ago
  I see. Then don't go "full ES6" but I prefer exporting an object with the class for reasons I've explained in a comment above. But I do see ES6 modules in the wild, some of them I'm using with other languages. So I guess it's fine to leave it as-is. Or if you want to ensure maximum compatibility, use babel as I suggested but add the sources to .npmignore so they're not duplicated in the published packages.

by DiThi 9y ago

SEJeff 9y ago

Why not send a PR?

toddmatthews 9y ago
teach a man to fish
- mhluongo 9y ago
  ... the PR would do that as well
  - bringtheaction 9y ago
    Not necessarily. PR on GitHub can be merged with the push of a button so it's more likely to be looked at only cursory before getting merged and therefore will be forgotten whereas when the author needs to retype it they will have a stronger memory of it and they remember where to go back and look next time
- hinkley 9y ago
  Give a man a fire, he's warm for a day. Set a man on fire, and he's warm for the rest of his life.
  - hetspookjee 9y ago
    This is brilliant.
    - hinkley 9y ago
      Terry Pratchett, RIP.
DiThi 9y ago
For other people in the comments that may have a similar problem.
igorgue 9y ago
AFAIK there's no upvotes on github ;-)
hinkley 9y ago
"The problem with doing something right the first time is nobody appreciates how hard it was."

allover 9y ago

> Don't do this: > module.exports = IPFSDropzone > Do this (and change documentation accordingly) > module.exports = {IPFSDropzone} Why? Exporting a single class for this kind of lib is preferable. I'd do: export default IPFSDropzone; See react-dropzone which does this [1]. (For that matter the author's questions around project setup would probably be answered by looking at react-dropzone's which looks pretty good). Also with npm scripts, local deps that expose executables are added to your PATH so you can call them directly, e.g. "prepublish": "babel *.js -d build/" [1] https://github.com/react-dropzone/react-dropzone/blob/master/src/index.js#L415 https://github.com/react-dropzone/react-dropzone/blob/master...

DiThi 9y ago
Because having a mix of libraries/modules which some export defaults and some don't makes it cumbersome to require them here and there: I have to remember which was exported as default and which had the class inside. Also it makes more obvious visually which variables are modules and which are classes/functions. For my projects I avoid default exports even when a module only has one class (which happens frequently). Additionally, ES6 default exports don't mix well with commonJS, sometimes I have to add require('foo').default for no apparent reason. > Also with npm scripts, local deps that expose executables are added to your PATH I think it didn't work reliably on windows or cygwin or something. I just tried and it works everywhere. Good to know! The only gotcha is that ";" and "&&" must have spaces around.

fiatjaf 9y ago

Thank you. But here are my concerns: * If I go ES6 I'll require all people importing it to also use an ES6 module bundler -- which means Babel only, or Rollup, which never works. * If I precompile and expect non-Babel people to use the precompiled then these people will have duplicated dependencies everywhere. Not complaining, but all this compatibility mess seems hard to me. I use Browserify!

DiThi 9y ago
I see. Then don't go "full ES6" but I prefer exporting an object with the class for reasons I've explained in a comment above. But I do see ES6 modules in the wild, some of them I'm using with other languages. So I guess it's fine to leave it as-is. Or if you want to ensure maximum compatibility, use babel as I suggested but add the sources to .npmignore so they're not duplicated in the published packages.