artembatura / zero-scriptsjs Goto Github PK

(errors which generated by fork-ts-checker-webpack-plugin)

We need to catch the performance regressions and have the availability to search ways for perf improvements

TypeScript support already added in extension.webpack-babel, but we need to have different ways to support TypeScript, who doesn't use extension.webpack-babel

• Remove extra text from ESLint warnings: Module Warning (from ./node_modules/eslint-loader/dist/cjs.js):
• Add message Starting the development server... for start task
• Do not emit source maps for d.ts files in publish build
• Rename PUBLIC_PATH to PUBLIC_URL

And separate to other package: extension.webpack-eslint.react

Current problem:
Base unit to begin using charms of modularity — Preset

For example:
We have extension.jest-spa, which add test script to any Preset
Key problem is what we doesn't use test script without Preset

In new design we haven't Preset more. New base unit is a Script
Every Script is a script.[toolName]-[appType].[scriptName] package
For example script.webpack-spa.start

For example, neutrinojs/neutrino@a0cb90a#diff-0e927ed484d8f688f01e656bd1bb1f1dL109

Describe alternatives you've considered
extension.webpack-babel-typescript or extension.webpack-typescript

It should be the same or better implementation.

Is your feature request related to a problem? Please describe.
For a example, currently extension.webpack-babel supports React by passing option react: true. In future, to add support other specific loader or plugin for specific technology (ex. Vue — vue-loader) we need add new option (vue: true for add vue-loader). Eventually we have many unused dependencies, if user doesn't use React or Vue, what does not comply with the principles of modularity

Describe the solution you'd like
To solve this problem we need to officially allow inherit extensions and add new logic to handle substitutability of extensions

Important behavior
If in devDependencies will find extensions with same parent before the last parent, we need to choose an extension whose parent-child tree is larger

Then

extension.webpack-babel becomes support only JS/ES
extension.webpack-babel.react, which inherit from extension.webpack-babel comes with support for React

If in project installed extension.webpack-babel and extension.webpack-babel.react, by logic we need to use extension.webpack-babel.react

Describe alternatives you've considered
We can just add presets option for add own presets. But this breaks zero configuration conception, if we doesn't provide separated package with Babel React support

Marked this as bug because I was thinking that this working

Feedback
Changelog

With compression

Since sass-loader can automatically detect what is the sass implementation is installed, we can allow to user choose the need sass implementation himself (currently it's how implemented in CRA)

We need to setup process for automatic updates usual dependencies. Currently Renovate Bot only update devDependencies. I think we just need pin all dependencies (^1.0.0 => 1.0.0)

A lot of fixes and features is not delivered yet starting from 0.4 release. All this changes will be in 0.5

CRA PR - facebook/create-react-app#6219

Original CRA issue: facebook/create-react-app#8835

extension.webpack-sass

Problem

Since findPlugin method requires Plugin class as argument it's affects that we cannot get some Plugin without having this plugin as dependency. So we cannot use plugin-webpack-react without plugin-webpack-babel and plugin-webpack-eslint. And it's breaks all modular approach.

Solution

Extend core API so that findPlugin method should accept name: string or id: string and it will give ability to get plugin instance without having this plugin in dependencies

• Controlled by plugin option
• Open link only when build is done

Discussion about general project questions

Is your feature request related to a problem? Please describe.
Now we write options for extensions and configs in common package.json

Describe the solution you'd like
Any options of Zero Scripts written in separated object, which keyed by zero-scripts property

Describe alternatives you've considered
None

It's caused by calling process.exit() when application build and then no verify request is done.
To reproduce, use middleware, which will fail build/throw exception and make request to devServer

As in vue-cli

Why not Yarn v1? Yarn v1 is not a stable package manager for monorepo, because we get some Typescript errors on CI of incompatible types from different versions of packages. But local build is works.

Why not Yarn v2? Yarn v2 have strict rules for dynamic imports which based on dependencies. Since our plugin packages is dynamically imported packages by @zero-scripts/core, so we cannot import any of plugins, because core package doesn't have this packages as dependencies.

After investigating: fork-ts-checker-webpack-plugin doesn't work in this case

Current Behavior
Currently to build we run parallel compilation on every package, which causes lags at start

Expected behavior
No lag at start and compilation much faster

Your thoughts
At this moment is not very slow. But in future it's maybe totally change. Zero Scripts may have very many separated packages and the compilation will slow down exponentially (theoretically)

Describe alternatives you've considered
We can run compilation at root package as in this example
Then we doesn't need to run build/watch script at every package