neutrinojs / neutrino Goto Github PK

it will give hints about what is needed to install separately

Hi guys!

I'm attempting to port over an existing project and ran into a weird issue with the vendor bundle. Whenever I specify libs that should be separated into a vendor bundle my output size grows more than 50%. Is it possible that any optimization webpack does by default (tree shaking/dead code elimination) isn't working properly in this case?

yarn build output with vendors libs specified:

Build completed in 42.511s

Hash: 0002a77160dcc6b2b2dd
Version: webpack 2.2.1
Time: 42522ms
                                  Asset       Size  Chunks                    Chunk Names
  vendor.f8bf2a3b1f89ece045e0.bundle.js     423 kB    0, 2  [emitted]  [big]  vendor
   index.26f8506068d851a07c0d.bundle.js    97.7 kB    1, 2  [emitted]         index
manifest.d964145258295b16c352.bundle.js    1.44 kB       2  [emitted]         manifest
                             index.html  866 bytes          [emitted]
                 components/App/App.css   29 bytes          [emitted]
Done in 45.86s.

Without vendor libs:

Build completed in 31.739s

Hash: 6fd1d1e707e64d8a52c2
Version: webpack 2.2.1
Time: 31744ms
                                  Asset       Size  Chunks                    Chunk Names
   index.ac4cb561b012e94cc29e.bundle.js     344 kB    0, 1  [emitted]  [big]  index
manifest.48289fc07ffd03e3f03c.bundle.js    1.41 kB       1  [emitted]         manifest
                             index.html  779 bytes          [emitted]
                 components/App/App.css   29 bytes          [emitted]
Done in 35.48s.

Only difference between the 2 runs is the removal of the vendor entry in package.json, which is the following:

"neutrino": {
    "entry": {
        "vendor": [
            "history",
            "react",
            "react-dom",
            "react-redux",
            "react-router",
            "react-router-redux",
            "redux",
            "redux-observable",
            "redux-thunk",
            "rxjs",
            "store"
        ]
    }
}

So please bare with me as I am new to neutrino and embarrassingly babel as well (actually one of the reasons I decided to proceed with neutrino).

I introduced a few features into my application that required babel-polyfill. Unfortunately adding it to my project was not as elegant as I would hope. I ended up with:

module.exports = ({ config }) => {
  const CWD = process.cwd()
  const SRC = path.join(CWD, 'src')
  const APP_ENTRY_PATH = path.join(SRC, 'index.js')

  config.entry('index')
     .delete(APP_ENTRY_PATH)
     .add('babel-polyfill')
     .add(APP_ENTRY_PATH)
}

This dance is required because I need to have babel-polyfill defined as an entry prior to my app entry file.

It would be great if there was either a mechanism to specify index (which may not be possible as the current data structure utilizes a Set), or a simpler api/toggle to add babel-polyfill.

My thoughts aren't completely wrapped around how this should behave, I just found it to be a clumsy experience (either due to the api, or due to my ignorance 😂).

From @gasolin on December 27, 2016 9:37

It's always happen when dev need to put some vendor libraries in code base.

Copied from original issue: mozilla-neutrino/neutrino-preset-web#7

Not a necessity for v4, but it would be nice to have a preset that adds flow capabilities to a project.

The story around HMR for React is pretty good, but practically non-existent for Node.js apps. Right now Neutrino skips any kind of separate build process for Node.js in development vs. production, just generating an identical build except with a different NODE_ENV. Let's see if we can get proper HMR support in the preset, and document how it can be integrated into Node.js apps.

I can't seem to find a way to change the src folder via configuration. Changing this line in the neutrino-preset-web preset solves it. Is there any way to do it properly?

From @gasolin on February 4, 2017 3:10

add --source/-s option to allow running single js file without any setup

ex: neutrino -p neutrino-preset-web -s app.js

that brings back the simplicity and the low entry barrier of web dev

inspired by the talk from react.js conf 2016

Copied from original issue: mozilla-neutrino/neutrino#11

Jest 19 introduces some breaking changes, but the only one used by the preset is renaming testPathDirs to roots. Still, this means a major version bump for the preset.

Right now we have main set in package.json, but obviously that's not able to be used since it just points to the neutrino bin. Maybe we can instead expose Neutrino as a requireable API as well which the CLI consumes.

Doing this could allow presets to augment Neutrino with additional functionality. This is probably the answer to #8, since we could provide an API for presets to inject the ability to include their own test provider.

On the flip side, this probably also means needing to return functions from presets rather than configuration. Also, overriding can't be done directly against an imported object.

// preset
module.exports = (neutrino) => {
  neutrino.configure({ ...someConfig });

  neutrino.addTestProvider('jest', (config) => {
    executeJestOrSomething(config);
  });
};

This project is awesome 👍 . But I didn't see preset about vue ~

In order to have custom variables available per environment for API keys and such, without committing anything to version control, in https://github.com/facebookincubator/create-react-app for example I can do the following:

1. add the following scripts to package.json:

  "start": "sh -ac '. .env.dev; react-scripts start'",
  "stage": "sh -ac '. .env.stg; react-scripts build'",
  "build": "sh -ac '. .env.prd; react-scripts build'",

2. add the following files to the root: .env.dev, .env.stg, .env.prd

3. define unique variables per environment to the .env files such as:

  REACT_APP_FOO='128376918237691287'
  REACT_APP_BAR='8476547869547955948'

4. access those variables anywhere in the source js as follows:

  console.log(process.env.REACT_APP_FOO);
  console.log(process.env.REACT_APP_BAR);

How would I accomplish this using Neutrino? I've tried replicating the same process using the neutrino start and neutrino build scripts but the environment variables end up undefined.

On https://github.com/mozilla-neutrino/neutrino-dev/ there's "No description or website provided." which makes this project look, well, immature ;)

The AirBnB linting rules we are using for the base preset and propagating to all other presets can be cumbersome to override. What if instead we extracted the linting preset out to its own? I could see this benefit as:

• neutrino-preset-airbnb
• neutrino-preset-standard

If a project really doesn't want linting, they can exclude it altogether. Thoughts?

Love this project! I created a simple neutrino preset for applying Prettier code formatting. I was wondering if there was a section in the docs or readme you were going to include all 3rd party neutrino presets for people to find?

I'd like to remove babel-preset-stage-0 from the React preset. The only real reason I had it included was it was needed in the past for Object rest spread. I think we should swap stage-0 out for babel-plugin-transform-object-rest-spread. The proposal is current at stage-3.

Looking at the stage presets for Babel, at the moment there is nothing really useful other than spread. I'll address this in the plugin work.

It's unclear to me from the customization section of the docs how to remove Hot Module Replacement fromneutrino-preset-web or React Hot Loader from neutrino-preset-react. @eliperelman could you provide an example?

From @gasolin on February 4, 2017 3:10

add --source/-s option to allow running single js file without any setup

ex: neutrino -p neutrino-preset-web -s app.js

that brings back the simplicity and the low entry barrier of web dev

inspired by the talk from react.js conf 2016

Copied from original issue: mozilla-neutrino/neutrino#11

{
  "config": {
    "presets": [
      "neutrino-preset-react"
    ],
    "neutrino": {
      "module": {
        "rule": {
          "css": {
            "loader": {
              "css": {
                "options": {
                  "modules": true
                }
              }
            }
          }
        }
      }
    }
  }
}

Here's the stack-trace:

⠋ Starting development serverError: No loader specified
    at Function.normalizeUseItem (<ROOT_PATH>/node_modules/webpack/lib/RuleSet.js:265:9)
    at Function.normalizeUse (<ROOT_PATH>/node_modules/webpack/lib/RuleSet.js:227:18)
    at use.map (<ROOT_PATH>/node_modules/webpack/lib/RuleSet.js:223:41)
    at Array.map (native)
    at Function.normalizeUse (<ROOT_PATH>/node_modules/webpack/lib/RuleSet.js:223:14)
    at Function.RuleSet.normalizeRule (<ROOT_PATH>/node_modules/webpack/lib/RuleSet.js:174:25)
    at <ROOT_PATH>/node_modules/webpack/lib/RuleSet.js:84:19
    at Array.map (native)
    at Function.RuleSet.normalizeRules (<ROOT_PATH>/node_modules/webpack/lib/RuleSet.js:83:16)
    at new RuleSet (<ROOT_PATH>/node_modules/webpack/lib/RuleSet.js:76:23)
    at new NormalModuleFactory (<ROOT_PATH>/node_modules/webpack/lib/NormalModuleFactory.js:46:17)
    at Compiler.createNormalModuleFactory (<ROOT_PATH>/node_modules/webpack/lib/Compiler.js:439:28)
    at Compiler.newCompilationParams (<ROOT_PATH>/node_modules/webpack/lib/Compiler.js:452:29)
    at Compiler.compile (<ROOT_PATH>/node_modules/webpack/lib/Compiler.js:461:20)
    at <ROOT_PATH>/node_modules/webpack/lib/Compiler.js:45:17
    at next (<ROOT_PATH>/node_modules/tapable/lib/Tapable.js:138:11)
    at Compiler.compilerInvalid (<ROOT_PATH>/node_modules/webpack-dev-middleware/lib/Shared.js:144:5)
    at next (<ROOT_PATH>/node_modules/tapable/lib/Tapable.js:140:14)
    at Compiler.compiler.plugin (<ROOT_PATH>/node_modules/webpack/lib/CachePlugin.js:32:5)
    at Compiler.applyPluginsAsyncSeries (<ROOT_PATH>/node_modules/tapable/lib/Tapable.js:142:13)
    at Watching._go (<ROOT_PATH>/node_modules/webpack/lib/Compiler.js:43:16)
    at Watching.<anonymous> (<ROOT_PATH>/node_modules/webpack/lib/Compiler.js:34:8)
error Command failed with exit code 1.

I tried to use the regex in the doc:

"test": "/\\.less$/"

But it doesn't apply for .less-files. Because we use new RegExp({regexp}) it checks for files named \.less{endOfString}\ (RegExp: /\/\.less$\//) instead of .less.

So it should be

"test": "\\.less$"

• What version of Neutrino are you using? 4.2.0
• Are you trying to use any presets? If so, which ones, and what versions? [email protected]
• Are you using the Yarn client or the npm client? What version? [email protected]
• What version of Node.js are you using? 6.9.5
• What operating system are you using? [email protected]

Using https://github.com/NekR/offline-plugin this could be pretty straightforward, and a win for everyone.

I came here yesterday via https://hacks.mozilla.org/2017/02/using-neutrino-for-modern-javascript-development/ My very immediate question was: Why should I use this instead of the 21k starred and 200 contributors strong create-react-app? But does it make different (better)?

Today I read https://hacks.mozilla.org/2017/02/using-neutrino-for-modern-javascript-development/#comment-20663 which makes some good points.

I think you should add/link this very FAQ somewhere prominently in the README.md (and rather not hide it in the FAQ)

PS I started using create-react-app a few weeks ago for a project. I did not consider neutrino, simply because I did not know about it at this time.

On https://neutrino.js.org/ these links, e.g. to the GitHub repo, are some # javascript stuff. So clicking on them with middle-mouse (to open in a new tab) does not work.

I want to use Neutrino to create NPM modules. I had figured I could use neutrino-preset-node for this. I'm having some trouble getting it working.

1. Create a new project, following the manual.
2. Build the project with yarn build (I added the build script mentioned in the manual)
3. Notice that the build folder contains an index.js

That's all well and good but it doesn't seem quite right.

Issues

• The first line of build/index.js looks like it references my local computer. That's no good if I want to deploy my module to NPM.

  require('/a/path/on/my/laptop/my-neutrino-based-npm-module/node_modules/source-map-support/source-map-support.js').install();

• When I link my module — using npm link — and link it into a local project — using npm link my-neutrino-based-npm-module — I get webpack errors. I'm importing my module into a react-redux-starter-kit project.

  import something from 'my-neutrino-based-npm-module'

  This is the error I get

  ERROR in /a/path/on/my/laptop/my-neutrino-based-npm-module/build/index.js
  Module build failed: ReferenceError: Unknown plugin "transform-runtime" specified in "base" at 0, attempted to resolve relative to "/a/path/on/my/laptop/my-neutrino-based-npm-module/build"
    at /a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-core/lib/transformation/file/options/option-manager.js:180:17
    at Array.map (native)
    at Function.normalisePlugins (/a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-core/lib/transformation/file/options/option-manager.js:158:20)
    at OptionManager.mergeOptions (/a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:36)
    at OptionManager.init (/a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-core/lib/transformation/file/options/option-manager.js:368:12)
    at File.initOptions (/a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-core/lib/transformation/file/index.js:216:65)
    at new File (/a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-core/lib/transformation/file/index.js:139:24)
    at Pipeline.transform (/a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-core/lib/transformation/pipeline.js:46:16)
    at transpile (/a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-loader/lib/index.js:46:20)
    at /a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-loader/lib/fs-cache.js:79:18
        at ReadFileContext.callback (/a/path/on/my/laptop/react-redux-starter-kit-example/node_modules/babel-loader/lib/fs-cache.js:15:14)
        at FSReqWrap.readFileAfterOpen [as oncomplete] (fs.js:365:13)
     @ ./src/routes/Home/components/HomeView.js 11:24-53
  

I would like to use Radium with neutrino-dev but it seems like neutrino does not come with babel plugins for class decorators or properties as in Radium's default usage. Is there any way to customize neutrino's babel configuration?

Would it be possible to allow setting (react) app's mount id to be something else than "root"?

It seems appMountId is currently set as part of the html-webpack-plugin initialization in neutrino-preset-web, but it is hard coded to "root".

Now, I've created a custom config for altering the value, which seems to do the trick, but feels somewhat error prone, as it relies on neutrino-preset-web using a specific html template:

// custom-config.js
'use strict';

const appMountId = 'custom-project-id';

module.exports = neutrino => {
  neutrino.config.plugin('html').args[0].appMountId = appMountId;
}

Would it be possible to set the value in some predefined way, possibly as:

1. env variable,
2. preset option,
3. general neutrino conf option,
4. some other way.

Hard coded id for a project is probably valid for modern SPA's, but there's a plenty of legacy and other reasons for needing it to be able to be changed per project, such as:

1. need for mounting multiple different projects on the same page,
2. not being able to use the id "root" on target page.

In order to support a better middleware story (for reasons below), I think handling requireing should be removed from the Neutrino API, and pushed into the CLI. Basically we switch the constructor to do nothing, and introduce something like .use() for injecting presets. This makes module resolution better for Neutrino, while giving preset authors and extenders a more consistent custom configuration API (i.e. death to .custom).

Prototyping and experimentation is happening at #86.

EDIT: This has evolved into something a little different than proposed below, see comments for current direction. Keeping this here for posterity.

Presets as code

The Neutrino constructor will no longer take an array of preset names/paths. Instead, a .use() or similar would accept a preset as code, probably some kind of middleware function:

use(preset) {
  preset(this);
}

package.json configuration

I'm thinking that merging of package.json data should also be moved into the CLI. We already have a mechanism for merging data, so the CLI just needs to call this on the configuration after .useing all the presets

const api = new Neutrino();

api.use(require('preset-alpha'));
api.use(require('preset-beta'));
api.config.merge(require('package.json').config.neutrino);

Along those lines, we should probably change the schema of config data in package.json so it can be aggregated into a single namespace. Looking at html and neutrino and custom and presets et al is...meh.

Maybe just a top-level "neutrino" is OK.

{
  "neutrino": {
    "presets": ["neutrino-preset-react"],
    "config": { "publicPath": "./" },
    "jest": { "bail": true },
    "mocha": { "reporter": "nyan" }
  }
}

Middleware configuration

The .custom configuration object is a hack that needs to go. Making preset authors manually put configuration on this, with no way to automatically merge this back from package.json makes things annoying. This blocks #23, and you can see evidence of this mess in the Jest preset. it would be nice if preset authors could also use the middleware concept to inject preset-specific configuration with automatic merging from additional arbitrary keys from the package.json neutrino object, e.g. jest, mocha. Maybe if .use() takes a key as well.

use(name, preset) {
  const custom = this.middlewareConfig[name];
  preset(this, custom);
}

// ...

module.exports = (neutrino, options) => {
  const mochaConfig = { ...defaults, ...options };
};

I know this is a lot of changes, so I'm saving this for v5 (obviously since these are breaking changes). I'd appreciate any thoughts on this, recommendations, or better practices.

From @gasolin on December 16, 2016 10:36

any generated example that I can check if that's what I want and fork from it directly?

The current README didn't indicate what file is needed in src/

Copied from original issue: mozilla-neutrino/neutrino-preset-react#2

Right now the Web preset only allows you to customize how HTML files are generated by passing configuration options to config.html in package.json. You are unable to change these values via a another preset or project-specific preset module.

• Consider moving these configuration options to neutrino.custom.html
• Consider being smarter about custom configuration by having Neutrino do a deep merge between neutrino.custom and package.json -> config.custom or something.

If you are using neutrino start with no devServer configuration and your target isn't node, a Webpack compiler.watch is created. This watcher doesn't show anything to the console, which can be offputting.

I can imagine a project might want to consume multiple presets:

• neutrino-preset-react
• a flow preset
• a SASS preset

By breaking up presets into smaller chunks, we could theoretically allow larger presets and projects to be compositions of many presets.

We would probably need to allow --preset to be used multiple times:

neutrino build --preset neutrino-preset-react --preset flow --preset sass

Also for package.json, probably switch preset to presets:

{
  "config": {
    "presets": [
      "neutrino-preset-react",
      "flow",
      "sass"
    ]
  },
  "scripts": {
    "build": "neutrino build"
  }
}

This information exists in the React preset docs, but not in the Web preset docs.

I recently started a project to try out Neutrino and while the initial setup was pretty easy, as soon as I wanted to make a change to the (eventual) webpack configuration I struggled to work out how to do it.

My first attempt to understand exactly what was ending up in webpack was to try to get ahold of the configuration object that webpack would receive. I was surprised to find there was no way to make neutrino output it, either using a --verbose flag or with a separate command. In the end I just added a custom preset which would print it out.

One of the biggest problems I observed using Grunt in production is that plugins you'd add would each modify the grunt configuration object, so that the actual configuration of tasks that'd be run would pass through many (often invisible) intermediate states before being used, making debugging impossible. I see a similarity here, in that after applying a couple of presets I had no way to know what webpack configuration was actually being used.

I think it'd be a good idea to make the underlying configuration more transparent to users - give them a way to see what it is before and after applying presets, and with different config properties switched on/off, and encourage them to use it in the documentation.

Moreover it'd give people a way to "eject" from Neutrino (borrowing the terminology from create-react-app), should they need to.

Hello,

first congratulations for the awesome work on Neutrino, I had very similar needs in the company I work for and the solution I came to is far less elegant than yours.

The applications I work on have a strong legacy and I don't have the possibility to change everything on their interface, so I need to generate JS/CSS bundles manually, currently my solution is a mix of webpack + gulp.

Is there maybe a way to support mutliple instances of webpack inside Neutrino ?

I know my requirements are quite particular but if this is possible for you, then I would probably switch our build stack to Neutrino and contribute a few features as well.

The docs for neutrino-preset-node are missing the rules and plugins that can be overridden and configured.

The Jest preset is an awesome step forward. A few more dependencies we should add:

• react-addons-test-utils
• enzyme

These allow more react-specific testing, like enzyme to create shallow JSX components. I also needed react-addons-test-utils just for tests to run.

I ported my homepage to based on neutrino-preset-react , and defined several css/scripts via config.html.scripts entry point in package.json

https://github.com/gasolin/gasolin.github.io/blob/source/package.json#L48

Though css works nicely, js file is not copied correctly.

There are some good resources about efficient caching in this document from Webpack:

https://webpack.js.org/guides/caching/

We should look into the best settings to use for each preset and make changes where necessary.

Some editor plugin will read eslint config from .eslintrc, it should be a JSON file or a JS module.

It's easy to create a simple one like that:

// filename: .eslintrc.js
const Neutrino = require('neutrino')
const pkgJson = require('./package.json')
const api = new Neutrino(pkgJson.config.presets)

// any better way?
let eslintrc = api.getWebpackOptions().module.rules[0].use[0].options

module.exports = eslintrc

And there are many other configs will be read by editor plugin: .editorconfig, .babelrc, etc.

One way should be generate all the configs with a command line interface like that:
neutrino gen-config --eslint --babel --editorconfig

Then it will create all the specify config files in your project root.

A regression from Neutrino 3.x. When Neutrino can't find a preset module, it doesn't properly throw.

I've tried getting neutrino linting presets to output hints to vscode and found some bugs.
neutrino.custom.eslintrc throws an exception because a global is undefined and assumes options.envs is an array of objects.

I guess Jest is the official testing mechanism for React projects, so it would be nice if you could provide a way to use Jest as the default when using neutrino-preset-react.

On a side note, I'm not sure I like the path that Neutrino is heading down for testing platforms. In order to execute testing, every test function lives in Neutrino itself, and configuration options are passed to it via the presets. This means Karma and mocha both live in Neutrino. Need to add Jest? Well it sounds like that needs a change in Neutrino as well. I'd like to see if there's a way we can overcome this while not putting any burden on the preset consumer.

Right now starting a dev server just has some ugly text. Gonna make this prettier.

node v6.9.1
npm 4.3.0

Running the test

$npm test

> [email protected] test /Users/frankg/dev/code/temp/neutrino/2-nuetrino-react
> neutrino test

/Users/frankg/dev/code/temp/neutrino/2-nuetrino-react/node_modules/neutrino/src/neutrino.js:34
          throw exception;
          ^

TypeError: Neutrino was unable to load the module 'neutrino-preset-jest'. Ensure this module exports a function and is free from errors.
Cannot read property 'has' of undefined
    at module.exports.neutrino (/Users/frankg/dev/code/temp/neutrino/2-nuetrino-react/node_modules/neutrino-preset-jest/src/index.js:68:28)
    at Neutrino.presets.forEach.exception (/Users/frankg/dev/code/temp/neutrino/2-nuetrino-react/node_modules/neutrino/src/neutrino.js:26:35)
    at Array.forEach (native)
    at Neutrino (/Users/frankg/dev/code/temp/neutrino/2-nuetrino-react/node_modules/neutrino/src/neutrino.js:17:13)
    at run (/Users/frankg/dev/code/temp/neutrino/2-nuetrino-react/node_modules/neutrino/bin/neutrino:35:13)
    at Object.<anonymous> (/Users/frankg/dev/code/temp/neutrino/2-nuetrino-react/node_modules/neutrino/bin/neutrino:48:1)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:394:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:509:3
npm ERR! Test failed.  See above for more details.

/test/add.test.js

describe('sanity check', () => {
  it('can it be true', () => {
    expect(true).toBe(true)
  });
});

package.json

{
  "name": "2-nuetrino-react",
  "version": "0.1.0",
  "description": "",
  "main": "index.js",
  "config": {
    "presets": [
      "neutrino-preset-airbnb-base",
      "neutrino-preset-react",
      "neutrino-preset-jest"
    ]
  },
  "scripts": {
    "start": "neutrino start",
    "build": "neutrino build",
    "test": "neutrino test"
  },
  "keywords": [],
  "author": "Frank Gutierrez",
  "license": "MIT",
  "dependencies": {
    "react": "^15.4.2",
    "react-dom": "^15.4.2"
  },
  "devDependencies": {
    "neutrino": "^4.2.0",
    "neutrino-preset-airbnb-base": "^4.2.0",
    "neutrino-preset-jest": "^4.2.0",
    "neutrino-preset-react": "^4.2.0"
  }
}

Following a faulty review on a Jest preset PR, it's clear that we need a more robust mechanism for ensuring things function properly before commit and publish. This should involve tests or actually running the presets in CI and verifying they don't throw non-zero exits or both.