Skip to content
This repository was archived by the owner on May 9, 2022. It is now read-only.

Conversation

@lrowe
Copy link

@lrowe lrowe commented Jun 27, 2014

Recursively copies src to package root converting modules with deamdify.

Additional transforms to require from 'lodash-node' instead of 'lodash-amd' and
fixup placement of 'use strict'; after deamdify.

Recursively copies src to package root converting modules with deamdify.

Additional transforms to require from 'lodash-node' instead of 'lodash-amd' and
fixup placement of `'use strict';` after deamdify.
@lrowe lrowe mentioned this pull request Jun 30, 2014
@TooTallNate
Copy link
Contributor

The thing about this solution is that a build system like this will be need to be put into place for every scribe repository.

I mean I'm game for that (though I'm just a user of scribe), but the scribe developers might as well just write the code CommonJS-style at that point, and then compile for AMD after-the-fact if we're really going to go a route like this.

@lrowe
Copy link
Author

lrowe commented Jun 30, 2014

These modules are published to bower (as RequireJS) as well as to npm, so which module version is considered the master is arbitrary - one will always need a build step.

@TooTallNate
Copy link
Contributor

Totally, I just feel like CommonJS has less boilerplate :)

@OliverJAsh
Copy link

We run deamdify as a global transform when you require Scribe through browserify: guardian/scribe#175

Yes, I hate RequireJS. Moving to CommonJS is not the solution. Moving to ES6 modules is (I hope).

@OliverJAsh
Copy link

The browserify workflow for Scribe is broken in a few places AFAIK, but I believe @TooTallNate is on it: #2

@OliverJAsh OliverJAsh closed this Jul 1, 2014
@lrowe
Copy link
Author

lrowe commented Jul 1, 2014

@OliverJAsh I think it's worth separating the discussion of what module format should be used for development from what module format should be published to any one of the various repositories. Given npm is largely a repository of CommonJS modules, I think there would be value in running the transform on publishing as it simplifies usage for those already within the npm ecosystem. (As mentioned in my post to the google group, this is the approach of projects built with coffescript or currently using ES6 modules.)

That being said, having usable npm modules even with a required transform would definitely be very welcome.

@TooTallNate
Copy link
Contributor

Moving to ES6 modules is (I hope).

Well let's do that then :) I don't think it's too early.

Like @lrowe is saying we can still run a pre-publish script for npm publish to compile them to CommonJS modules, and I'm sure there's a way to get the running with RequireJS as well.

@theefer
Copy link
Contributor

theefer commented Jul 1, 2014

@TooTallNate Fair enough. I've given it a go for a simple plugin guardian/scribe-plugin-heading-command#2. Would be good to have people look at the result and try out the AMD and CommonJS output to prove it's viable.

@OliverJAsh
Copy link

@theefer Nice.

Now it's worth talking about how we should address the original issue here:

  • We could run traceur.toCjs in a Plumber pipeline on npm pre-publish, so that consumers receive CommonJS?
  • Can browserify users consume ES6 modules, so we don't have to do anything? Is this a feasible expectation?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants