Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Joe Pea
    @trusktr
    Yeah, basically what you do is list your dependencies inside of npm.json. Those deps can have ES6 modules. Then, in an entry.js file, you can import whatever you need (npm deps, or other local files).
    That's the gist of it.
    @jzempel ^
    Jonathan Zempel
    @jzempel
    I did that. rocket:module choked on the ES6 exports syntax in the NPM modules.
    Joe Pea
    @trusktr

    @jzempel rocket:module currently works with the PLUGINS-PREVIEW@2 version of Meteor. Are you using that?

    meteor update --release PLUGINS-PREVIEW@2

    then

    meteor add rocket:module@0.6.0

    and make sure that your .meteor/versions file contains version 0.6.0 for rocket:module.

    Jonathan Zempel
    @jzempel
    I was using PLUGINS-PREVIEW@2. I didn't specify a version for rocket:module. I'll try that.
    Joe Pea
    @trusktr
    Then rocket:module looks for entry.js or *.entry.jsfiles to compile. Rule of thumb: any file that you don't import wil be handled by Meteor, not rocket:module, so if you have a file that isn't imported into anywhere (ultimately starting at your entry point entry.js file) then Meteor will read that, and it'll complain about the export syntax.
    entry.js files can import files, which can import files, which can import files, etc. entry.js -> file1.js -> file2.js -> etc. So if your file isn't in the import chain, then it'll be handled by Meteor and Meteor will choke.
    Files in a modules folder are cmopletely ignored by Meteor regardless of whether they are in an import chain or not.
    Jonathan Zempel
    @jzempel
    ok, I just setup a new app using the PLUGINS-PREVIEW@2 release and rocket:module@0.6.0. I added a private package import to npm.json. And entry.js contains: import { TabComponent, TablistComponent } from 'js-tabs'; On starting meteor, I get this error ...
    While processing files with rocket:module (for target web.browser):
    shared-modules.js: ./~/js-tabs/src/index.js
    Module parse failed: [app]/.meteor/local/rocket-module/platform-builds/web.browser/node_modules/js-tabs/src/index.js Line 5: Unexpected reserved word
    You may need an appropriate loader to handle this file type.
    |  */
    |
    | export { default as TabComponent } from './tab_component';
    | export { default as TablistComponent } from './tablist_component';
    | export { default as TabpanelComponent } from './tabpanel_component';
    @ ./packages/rocket_module___app/entry.js 3:16-37
    Joe Pea
    @trusktr

    @jzempel Ah, it's because rocket:module is ignoring node_modules folders (where your package is being installed to):

                module: {
                    loaders: [
                        { test: /\.jsx?$/,  loader: 'babel', exclude: /node_modules/ },
                    ]
                }

    I can change this. The thing is that if I enable it for node_modules folder, it cause Webpack to apply the babel-loader to every single file that gets imported from node_modules (that can be a whole ton) so it will make load time a lot slower.

    The good thing is that I will add caching by v1.0 so the long load time will only be during the initial build, and fast thereafter.

    Anyway, the recommended practice is to publish packages on npmjs.com (or wherever your registry is) using NPM's supported module format: CommonJS.

    Here's an example of what you can do: https://github.com/trusktr/react-famous/tree/joe

    Take a look at the scripts section inside the package.json file. The prepublish script compiles everything into CommonJS format using Babel. The idea is all the code is written inside the src folder (using any module format, like ES6 Modules) then when you run npm publish to publish the package, it compiles to CommonJS in the root of the project, for npm. Also check out .gitignore and .npmignore.

    Jonathan Zempel
    @jzempel

    Right - I'm aware of the typical transpile step during prepublish. But this is a private package and I'd like to keep it build-agnostic inside my organization.

    I think I read somewhere that you have plans to add app- and/or package-specific support for webpack configs. Hopefully that would allow me to include node_modules for babel-loader.

    Jonathan Zempel
    @jzempel
    Also, I think that while it's industry assumption that CommonJS is the format-of-choice for npm client-side packages, that's not necessarily npm's opinion: http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging
    Joe Pea
    @trusktr

    @jzempel I feel your sentiment about packages being "build-agnostic". That's why I made the package.json the way it is: CommonJS is the defacto in Node.js (whether NPM likes it or not) so I compile all my libraries to that format during prepublish. Also, all the major build tools (Webpack, Browserify, JSPM) all support CommonJS out of the box, so CommonJS is the common point currently, so it makes lots of sense to compile to CommonJS during prepublish (in current times at least, that may change once ES6 Modules become official features in JavaScript engines). So for now, I think it makese sense to compile to CommonJS...

    ... Then (at least in current times) you package is build-agnostic because CommonJS works in any build system. I also provide the other scripts (build-amd, etc) in case people want to use those to make the library work in other environments (f.e. RequireJS).

    Your whole team can write in ES6, and a single republish script can convert to CommonJS. I don't really see any problems with that.

    Anyhow, I would indeed like to make it easier to use libraries of any format.

    I don't know how we'll do this yet. Here's the thing: in order for Webpack to do dependency sharing (via code splitting) across packages of an app and the app itself, there needs to be a single instance of Webpack compiling everything, and hence a single configuration for the whole thing.

    It would be possible to use a separate instance of Webpack for each package, allowing per-package configuration, but at the cost of no more dependency sharing (at least not the way Webpack is currently written), so there will be opportunity for duplicate libraries in a given app (which is one of the main things rocket:module aims to prevent).

    Joe Pea
    @trusktr

    So, since there's a single instance of Webpack handling the entire build (compiling all the files of all packages in an app and the app itself (except for files that are not in an import chain)), if a package were to specify a custom loader aimed at targetting files of a certain NPM package, then multiple Meteor packages can be affected by this if they all depend on the same package.

    So, based on how Webpack works, the key to making this work as easily as possible is preparing an NPM package to work without needing a loader of any sort, and that means writing with the currently-defacto-standard CommonJS module format (or compiling to that format in prepublish).

    I was debating between Webpack and Browserify. It'd be possible to have package-specific transforms with Browserify, but then your package is becoming the opposite of build-system-agnostic.

    Hmmmmmm..... There is a transform-loader for Webpack, for using browserify transforms. Maybe that can be used to execute package-specific browserify transforms on a package (like yours). So, if we use transform-loader, then you can write your NPM package in a way that it's compatible with Browserify. Rocket:module can use transform-loader to apply your packages transform.

    but anyways, that then is just a form of postpublish handling instead of prepublish handling. There's really no difference except for the transpile happens after publishing.

    Joe Pea
    @trusktr

    In my opinion, prepublish transpiling into the most commonly used module format (CJS currently, as far as build systems are concerned) is best in order for a library to be the most consumable with the least friction.

    I think I'm leaning towards enabling the babel-loader for all files, node_modules included, and just make sure it wel documented. Maybe there can be an app-level setting for switching this on and off, along with the necessary note in the docs that the initial build may be initially sloooooooow.

    @jzempel
    I might consider switching to JSPM when 0.17.0 is released. JSPM supports all module formats for all things, NPM packages included, out of the box (no loaders or transforms need to be added). Rocket:module's usage API would remain the same, only the internals would change (using JSPM instead of Webpack).
    If you have any ideas or suggestions, please do let me know. : ]
    Jonathan Zempel
    @jzempel
    @trusktr fwiw, I think I've come around to accepting the need to bundle transpiled CJS with my private ES6 npm component packages. I'm not saying I like it – it feels like I'm checking-in binaries and imposing maintenance overhead. But it turns out meteor+rocket:module isn't the only framework where it feels like I'm swimming against the current (having similar issues with ember-cli). So I'm down with your package using the exclude: /node_modules/ webpack config.
    Joe Pea
    @trusktr
    @/all I'm adding the cache feature right now, for faster builds.
    Jonathan Zempel
    @jzempel

    @trusktr I'm coming back to this for another try after a couple of weeks away. I've tried with various combinations of meteor+rocket:module (right now I'm using meteor@1.2-rc.12 + rocket:module@0.8.2), but the outcome is always the same:

    W20150908-13:58:59.516(-7)? (STDERR)          
    W20150908-13:58:59.517(-7)? (STDERR) /Users/jzempel/.meteor/packages/meteor-tool/.1.1.7-rc.12.isimno++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:245
    W20150908-13:58:59.517(-7)? (STDERR)                         throw(ex);
    W20150908-13:58:59.517(-7)? (STDERR)                               ^
    W20150908-13:58:59.540(-7)? (STDERR) ReferenceError: Element is not defined
    W20150908-13:58:59.540(-7)? (STDERR)     at entry.js:1752:1
    W20150908-13:58:59.540(-7)? (STDERR)     at Object.exports.__esModule (entry.js:1774:1)
    W20150908-13:58:59.540(-7)? (STDERR)     at __webpack_require__ (packages/rocket_module/shared-modules.js:52:1)
    W20150908-13:58:59.540(-7)? (STDERR)     at Object.exports.__esModule (entry.js:1468:1)
    W20150908-13:58:59.540(-7)? (STDERR)     at __webpack_require__ (packages/rocket_module/shared-modules.js:52:1)
    W20150908-13:58:59.540(-7)? (STDERR)     at Object.exports.__esModule (entry.js:82:1)
    W20150908-13:58:59.540(-7)? (STDERR)     at __webpack_require__ (packages/rocket_module/shared-modules.js:52:1)
    W20150908-13:58:59.541(-7)? (STDERR)     at Object.exports.__esModule (entry.js:22:1)
    W20150908-13:58:59.541(-7)? (STDERR)     at __webpack_require__ (packages/rocket_module/shared-modules.js:52:1)
    W20150908-13:58:59.541(-7)? (STDERR)     at webpackJsonpCallback (packages/rocket_module/shared-modules.js:23:1)
    => Exited with code: 8

    I'm using the following npm.json:

    {
      "domtastic": "^0.11.1"
    }

    Any ideas about what I might be missing?

    Oh, and the following entry.js:
    import $ from 'domtastic';
    Joe Pea
    @trusktr
    @jzempel Can you post your example repo? That will help figure it out. Sorry, I was at Burning Man for the past days. :D
    @jzempel What is the Element symbol? Where are you expecting to get that from?
    import Element from 'where?'
    Jonathan Zempel
    @jzempel
    yeah, not sure where Element comes from. If I comment-out the import $ from 'domtastic' the error goes away.
    Joe Pea
    @trusktr
    Ah.
    That is because that library domtastic must be expecting some global variabel Element to exist.
    Which means that library may not have been designed with newer module conventions in mind (i.e. not made for CommonJS, AMD, or ES6 modules).
    Hmm
    nevermind. It seems to be written in ES6.
    @jzempel If you can find the line in domtastic where that error happens, you might be able to report it to them to fix it.
    There's probably no way for us to fix it unless we know what domtastic is doing (I've never used domtastic before).
    @jzempel ah!!!
    Where is your entry point file (entry.js) located?
    Make sure you're not running it on the server side.
    Because in that case the server side doesn't have any browser stuff like Element.
    So, for example, but your entry point at client/entry.js to use it only on the front-end.
    Joe Pea
    @trusktr
    Either that, or use Meteor.isClient or Meteor.isServer in your entry point to conditionally run code.
    Jonathan Zempel
    @jzempel
    yeah, this was happening on various ES6 modules (not just domtastic). But I had entry.js in the root. Moving it to a client/ directory seems to have fixed the issue. Thanks!
    Joe Pea
    @trusktr
    @jzempel No probs! Just remember that where you place your entry point files still matters, and Meteor will use that to determine where it runs.
    Jonathan Zempel
    @jzempel
    got it. thx.
    Joe Pea
    @trusktr
    In my projects, I typically have to entry points: server/entry.js and client/entry.js
    THen, I put shared modules in a root level folder modules, modules that get used on both sides.
    THen I have a modules folder in both the server and client folders for modules specific to each side.
    Joe Pea
    @trusktr
    DEPRECATED (a long time ago) -- I won't monitor this channel anymore.