Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linaria 1.0 roadmap #214

Closed
8 of 12 tasks
satya164 opened this issue Sep 14, 2018 · 2 comments
Closed
8 of 12 tasks

Linaria 1.0 roadmap #214

satya164 opened this issue Sep 14, 2018 · 2 comments

Comments

@satya164
Copy link
Member

satya164 commented Sep 14, 2018

The next rewrite is at: https://github.com/callstack/linaria/tree/next

Summary

  • Different architecture - Previously the Babel plugin used to write CSS files to the disk, this caused many issues:
    • We have to deal with environment variables to prevent writing files
    • We have to use separate options for testing and SSR to prevent these files from getting written
    • Files keep getting written multiple times when rebuilding in webpack, which in turn triggers multiple rebuilds
    • single: true with babel-cli doesn't work properly as it operates on each file in a separate process which can cause issues like Missing classes in output - depending on filename #204
    • Tests are very complex and debugging is harder due to we having to read output from stdout
      Now the Babel plugin writes the CSS as a comment in the file and the webpack loader write the actual files, which avoids all these issues, makes tests significantly simpler.
  • Sourcemap support - Users can jump to the JS file where the style was declared from devtools
  • Proper dependency tracking - The babel plugin can output the dependency list so that the webpack loader can properly mark the dependencies for the file
  • A simplified module system - Previously the module system tried to implement all the methods supported in Node. Now we just support the minimum required API (module.exports, exports, require, require.resolve, __filename and __dirname), which makes the codebase simpler, more maintainable are consistent with webpack
  • Restricted sandbox when evaluating code - We prevent access to node's native modules when evaluating because you wouldn't be able to do it with webpack, people should use something like babel-plugin-preval to do those
  • React bindings with styled helper ala styled-components which uses CSS custom properties for dynamic properties

This will be a breaking change and will require using both the Babel plugin and Webpack loader. It'll also address many outstanding issues: #169, #198, #204, #206, #208, #209

TODO

@satya164 satya164 changed the title Linaria 2.0 roadmap Linaria 1.0 roadmap Sep 18, 2018
@chrisbateman
Copy link

chrisbateman commented Sep 28, 2018

So I guess Linaria will no longer be able to be used with libraries or other projects that don't use Webpack?

Just confirming. I definitely understand it's tricky to do with Babel alone

@satya164
Copy link
Member Author

@chrisbateman for the next release, we'll only have a webpack loader. but eventually we'll write integrations for more bundlers. we're also working on a CLI (#227) for libraries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants