question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Please don’t publish experimental syntax on npm

See original GitHub issue

Hi, I help maintain React and some other projects like Create React App. 👋

I recently saw in this issue (https://github.com/facebook/create-react-app/issues/4648#issuecomment-398540069) that this project uses experimental syntax (such as class properties) as part of the npm entry point.

I strongly encourage you to reconsider this decision. If the class properties transform ends up changing (which is very likely) or abandoned (not as likely, but could happen), having uncompiled packages on npm using it will create a huge amount of churn for everyone (including maintainers of this project). Not to mention this makes the project unusable in any environment that respects the spec (such as Node.js).

Please compile any experimental syntax away before publishing. If you’re convinced that keeping import uncompiled is worth it (which is a whole separate can of worms as you can see in https://github.com/graphql/graphql-js/issues/1248), please compile at least the non-standard syntax away when publishing. That includes JSX too.

I understand this might seem like an inconvenience now. But it will be much better to do now than deal with pain for months when build tools and the spec changes. Thanks.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:8
  • Comments:8 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
moog16commented, Jun 20, 2018

Yes that was our initial thought. I’ll bring this to the team in the morning so that we’re all on the same page to reach a consensus. But my thinking right now is at the very least updating the npm entry points for the packages.

1reaction
gaearoncommented, Jun 20, 2018

I think that would be a great first step!

But my understanding is that you still want to provide a source version so I’d love to learn why. If it’s just for better tree shaking with e.g. webpack, then you could provide a version with import/export (but still no experimental syntax) instead.

Read more comments on GitHub >

github_iconTop Results From Across the Web

How to solve Support for the experimental syntax 'jsx' isn't ...
Missing script: "dev" because you don't have dev script. You can try : installing npm install --save-dev nodemon; add "dev": "nodemon ./bin/ ...
Read more >
дэн on Twitter: "@sebinsua Exactly" / Twitter
I wrote this in an issue for a library that shipped uncompiled experimental syntax (class properties) in its npm entry point. The specific...
Read more >
npm-publish - npm Docs
Description. Publishes a package to the registry so that it can be installed by name. By default npm will publish to the public...
Read more >
@babel/eslint-parser - NPM Package Overview - Socket
ESLint parser that allows for linting of experimental syntax transformed by Babel. Version: 7.19.1 was published by nicolo-ribaudo.
Read more >
Command-line API | Node.js v19.3.0 Documentation
--inspect-publish-uid=stderr,http; --insecure-http-parser ... please file a report in the Node.js issue tracker and link to it in the tracking issue for ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found