@jdalton @sindresorhus @rauschma @IgorMinar @TheLarkInn @kentcdodds @dan_abramov @Rich_Harris
Hello fellow open source publishing/bundling folks... I want to start a public discussion about the current "state of the art" for libraries publishing JavaScript modules... 1/6
-
Show this thread
-
Basically, RxJS is going to undergo (mostly cosmetic) changes over these next few months, and I think it's a good time for us to revisit our strategy for publishing different module types. 2/6
1 reply 0 retweets 3 likesShow this thread -
Currently, RxJS is publishing: ESM5, ESM2015, CJS, and a single "kitchen-sync" UMD (for classic global script-tag style imports), as well as TypeScript source files for source mapping. Honestly, it's a little out of control. 3/6
3 replies 1 retweet 3 likesShow this thread -
In your _opinion_, where are we headed? When will be the proper time to just publish ESM2015 (with extensions or whatever we need to do) and forgo building CJS/ESM5 etc? 4/6
1 reply 0 retweets 1 likeShow this thread -
With the advent of things like
@codesandbox,@stackblitz, and@unpkg, is it even necessary that we publish big UMD globals anymore? 5/62 replies 0 retweets 3 likesShow this thread -
Can we all, collectively, decide on one format and push things in that direction over the next year so I can stop building 3-4 different things? 6/6
13 replies 1 retweet 16 likesShow this thread -
Replying to @BenLesh
//
@kristoferbaxter@_developit ^ These two working on same problem1 reply 0 retweets 3 likes -
The format is up for debate, what's most important is adding metadata to packages so we know what format (syntax level) it's in.
1 reply 0 retweets 2 likes -
Well, it seems, at the very least, the "most modern" format is desirable so downstream tooling can do differential loading. I think
@Rich_Harris is onto something with ditching CJS for UMD, and dropping ES5.1 reply 0 retweets 2 likes -
Replying to @BenLesh @_developit and
Dropping ES5 means consumers will have to transpile node modules more frequently. Not sure yet this is the right move. Agree on dropping everything but esmodules compatibile, ES5 + esmodule import/export, and UMD. All of these variants need a standardized name in a field/file.
2 replies 0 retweets 4 likes
People have hide behind build performance as an excuse for not transpiling node_modules which is a shame as there's a ton of benefits. Tools should either be faster or developers should just deal with it.
-
-
Agree mostly in the long run. However, it's a substantial jump from the current. An approach which migrates the existing ecosystem to differential serving, allows modules to publish stage 4 compatible code, and allows for caching of intermediary transpiled code seems ideal.
0 replies 0 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
he/him 