fusionjs / fusion-cli Goto Github PK

We should have an easy way to run your tests in debug mode for both browser and node tests.

see build/compiler.js

See build/compiler.js

It would be nice if the cli had options for building + running only browser or only node tests.

See build/compiler.js

After introducing code coverage[1] we started seeing memory issues on Buildkite. Possibly due to subprocess instrumentation, need to investigate.

[1]b1bcee7

See build/instrumented-import-dependency-template.js

We may like to make nyc reporters configurable(allow passing along --reporters) in the future, but for now, we want to ensure we have the followings:

• text
• html
• cobertura

See build/compiler.js

See test/compiler/api.js

see build/compiler.js

Something like build --production --watch

Due to the way we have dependencies between browser and node builds, the test build will fail if a server test entry imports a file that uses chunk-id-loader and no client entry imports the same file.

(server) ../fusion-cli/build/chunk-id-loader.js!./src/components/translations.js
Module build failed: Error: no result from manifest for /Users/ganemone/dev/graphene-example/src/components/translations.js
    at _generateSource (/Users/ganemone/dev/fusion-cli/build/chunk-id-loader.js:27:24)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
 @ ./src/components/translations.js 37:30-135
 @ ./src/__tests__/server.node.js
 @ ../fusion-cli/node_modules/multi-entry-loader?include[]=/Users/ganemone/dev/graphene-example/src/**/__tests__/*.js,exclude[]=/Users/ganemone/dev/graphene-example/src/**/__tests__/*.browser.js
 @ multi __SECRET_MULTI_ENTRY_LOADER__?include[]=/Users/ganemone/dev/graphene-example/src/**/__tests__/*.js,exclude[]=/Users/ganemone/dev/graphene-example/src/**/__tests__/*.browser.js

This brings up a broader issue of testability of code that includes virtual modules. We should fix this issue, and enumerate all our virtual modules and ensure that code that uses them is testable.

Ensure this works nicely with error stack traces.

See build/compiler.js

We should ensure there is a unhandledRejection handler for both browser and server tests. Also, browser errors are often not logged at all, only reported if you debug your tests with devtool.

This should behave the same way that dev does. On test failure, we should wait for a recompilation and then re-run tests.

fusion start --environment=test is equivalent to fusion test --skip-build. We should remove it to simplify the CLI API. (Also, it doesn't actually work)

To actually check the entry point file path src/main.js

It is currently enforced that unit tests live in a top-level tests directory. This can make it annoying to write unit tests, so instead, test directories should be able to exist anywhere in src/, colocated with appropriate code.

See build/compiler.js

see build/compiler.js

See build/compiler.js

yargs help is currently incomplete, given the arguments that are actually used by the handler functions. Unneeded options should be removed, options of the form no-something should be handled correctly, and other valid options should appear in --help

Tape depends on __dirname working

There needs to be docs on babel configuration

• how to do it
• warnings around instability

There is a bug in the template string causing a variable to not be interpolated correctly.

The dev command currently will crash if there are compiler errors on the initial compilation. We should make sure we are catching and reporting these errors, and keeping a watcher alive.

Folks should be able to add additional plugins/presets on top of the built-in transformations.

See:
build/babel-plugin-experimentation/index.js
build/babel-plugin-i18n/index.js

I'm trying to write a custom renderer for fusion (replacement of fusion-react), and in order to SSR I need to be able to extract information from the context during the request.

Sorry if this is already supported, I haven't been able to figure out the best way to thread context through to the renderer initialization.

Fort internal release we're adding all polyfills for all core-js/ES6 and core-js/ES7. The concern is that these will be expensive and make it harder for apps to take full advantage of the performance release.

Fully document the cost of polyfills.

see build/instrumented-import-dependency-template.js

It is a much better experience to have NODE_ENV overridden
when running fusion dev and fusion test than throwing.
In production, we should still error on the side of caution
and throw, however in dev/test it should suffice to log a warning