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

REPL: be able to search/add plugins/presets from npm and try them out #858

Closed
hzoo opened this Issue Jun 27, 2016 · 12 comments

Comments

Projects
None yet
4 participants
@hzoo
Member

hzoo commented Jun 27, 2016

screen shot 2016-06-27 at 4 22 44 pm

The idea could be to have a search bar or something that could at least download the plugin and then recompile in the repl (w/ https://npmcdn.com/ + modifying scripts/repl.js which uses https://github.com/Daniel15/babel-standalone)? that or we use ASTExplorer somehow

I know there's tonicdev/webpackbin but I don't think we can use those themselves to augment the repl - maybe need to see how it works? edit: also requirebin

  • how to load a plugin from npmcdn (sounds like we need umd builds)
  • how to add/remove/modify plugin options in babel.transform in the UI
  • make it work with the saved url
@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jul 1, 2016

Member

Or instead of making every babel plugin export a UMD build (or download the cjs version and transpile to umd which would limit to a single file plugin), something with tonicdev? @boucher

Member

hzoo commented Jul 1, 2016

Or instead of making every babel plugin export a UMD build (or download the cjs version and transpile to umd which would limit to a single file plugin), something with tonicdev? @boucher

@tolmasky

This comment has been minimized.

Show comment
Hide comment
@tolmasky

tolmasky Jul 1, 2016

So, here are a number of thoughts (given stuff we are trying on tonicdev):

  1. You can theoretically accomplish this today with Tonic by doing require("babel-register")(...), however, the problem we have is that babel takes forever to load on Tonic. This is a performance issue on our end with the way we handle packages and babel needing to require thousands of files (for example, babel-preset-es2015 calls require 6640 times). Hopefully we will be able to deliver better times on this.

If we got this working, then you can conceivably pull this off with a Tonic embed. You'd have two notebooks, your plugins definition, which then requires the main repl. You can have the embed be secret, and have a nicer UI where you just checkbox plugins or type your own in, and under the hood you generate it.

  1. We are currently thinking a lot about the right way to handle Babel. For example, we want to default to native features as often as possible (so in node 4 not use arrow function babel etc). Right now, we do this manually by including the right plugins per node, but we are moving to a model of feature detection which will allow cool stuff like for example using babel in non-strict node 4 classes, but not babel is strict node 4 classes.
  2. Along with this comes the issue that we currently babel-ify the code you edit, but not any packages your require. Again, perhaps (1) is the answer here, but maybe we should be auto-applying babel to everything else as well? Its kind of weird because you now have 4 components that define "changes" in a file: 1. the code itself, 2. the versions of the packages in use, 3. the version of node, and 4. the secret version of babel. If we made this "explicit", in other words have the package reveal its using babel, you can imagine being able to add plugins or.

tolmasky commented Jul 1, 2016

So, here are a number of thoughts (given stuff we are trying on tonicdev):

  1. You can theoretically accomplish this today with Tonic by doing require("babel-register")(...), however, the problem we have is that babel takes forever to load on Tonic. This is a performance issue on our end with the way we handle packages and babel needing to require thousands of files (for example, babel-preset-es2015 calls require 6640 times). Hopefully we will be able to deliver better times on this.

If we got this working, then you can conceivably pull this off with a Tonic embed. You'd have two notebooks, your plugins definition, which then requires the main repl. You can have the embed be secret, and have a nicer UI where you just checkbox plugins or type your own in, and under the hood you generate it.

  1. We are currently thinking a lot about the right way to handle Babel. For example, we want to default to native features as often as possible (so in node 4 not use arrow function babel etc). Right now, we do this manually by including the right plugins per node, but we are moving to a model of feature detection which will allow cool stuff like for example using babel in non-strict node 4 classes, but not babel is strict node 4 classes.
  2. Along with this comes the issue that we currently babel-ify the code you edit, but not any packages your require. Again, perhaps (1) is the answer here, but maybe we should be auto-applying babel to everything else as well? Its kind of weird because you now have 4 components that define "changes" in a file: 1. the code itself, 2. the versions of the packages in use, 3. the version of node, and 4. the secret version of babel. If we made this "explicit", in other words have the package reveal its using babel, you can imagine being able to add plugins or.
@xtuc

This comment has been minimized.

Show comment
Hide comment
@xtuc

xtuc Jul 11, 2017

Member

Also https://runkit.com is a possibility.

Member

xtuc commented Jul 11, 2017

Also https://runkit.com is a possibility.

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jul 11, 2017

Member

👍 Yeah ^ it was tonicdev when I first talked about this

Member

hzoo commented Jul 11, 2017

👍 Yeah ^ it was tonicdev when I first talked about this

@CompuIves

This comment has been minimized.

Show comment
Hide comment
@CompuIves

CompuIves Jul 11, 2017

Hmm, this is an interesting issue. Would love to help out.

CodeSandbox and WebpackBin use the same service to package all npm dependencies, simply said we create a UMD build for any given combination of packages and cache it.

In the case of CodeSandbox the transpiling (using babel) is done in the browser. This is already modular, as in, you could add any babel plugin as long as they don't rely on node native modules to work (recently added CompuIves/codesandbox-client#16).

I don't think it should be a lot of work to add this functionality to the REPL as well, I can hack at it this weekend.

CompuIves commented Jul 11, 2017

Hmm, this is an interesting issue. Would love to help out.

CodeSandbox and WebpackBin use the same service to package all npm dependencies, simply said we create a UMD build for any given combination of packages and cache it.

In the case of CodeSandbox the transpiling (using babel) is done in the browser. This is already modular, as in, you could add any babel plugin as long as they don't rely on node native modules to work (recently added CompuIves/codesandbox-client#16).

I don't think it should be a lot of work to add this functionality to the REPL as well, I can hack at it this weekend.

@tolmasky

This comment has been minimized.

Show comment
Hide comment
@tolmasky

tolmasky Jul 12, 2017

We've recently done a big push to ramp up embed use, so now might be a good time to chat. I think there would still be some challenges, but we're in a good place now to possibly start tackling them.

tolmasky commented Jul 12, 2017

We've recently done a big push to ramp up embed use, so now might be a good time to chat. I think there would still be some challenges, but we're in a good place now to possibly start tackling them.

@xtuc

This comment has been minimized.

Show comment
Hide comment
@xtuc

xtuc Jul 12, 2017

Member

Should we organize a video call to talk about that? Are you on Slack already?

Member

xtuc commented Jul 12, 2017

Should we organize a video call to talk about that? Are you on Slack already?

@xtuc

This comment has been minimized.

Show comment
Hide comment
@xtuc

xtuc Dec 6, 2017

Member

An idea, we can use bundle.run for that. For example if you require https://bundle.run/babel-plugin-tailcall-optimization@1.0.11 it provides a babelPluginTailcallOptimization variable containing the plugin, we can then just call the entrypoint with babel-types and register it in babel-standalone.

Member

xtuc commented Dec 6, 2017

An idea, we can use bundle.run for that. For example if you require https://bundle.run/babel-plugin-tailcall-optimization@1.0.11 it provides a babelPluginTailcallOptimization variable containing the plugin, we can then just call the entrypoint with babel-types and register it in babel-standalone.

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Jan 23, 2018

Member

#1518 by @xtuc is pretty related to this

Member

hzoo commented Jan 23, 2018

#1518 by @xtuc is pretty related to this

@hzoo

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Apr 17, 2018

Member

Was done in #1518 and should be easier via codesandbox rewrite

Member

hzoo commented Apr 17, 2018

Was done in #1518 and should be easier via codesandbox rewrite

@hzoo hzoo closed this Apr 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment