refactor: split one `linaria` package into multiple `@linaria/*` #687

Anber · 2020-10-28T18:09:53Z

Motivation

Closes #413

Summary

The list of packages:

@linaria/babel
@linaria/cli
@linaria/core
@linaria/extractor
@linaria/logger
@linaria/preeval
@linaria/react
@linaria/rollup
@linaria/server
@linaria/shaker
@linaria/stylelint
@linaria/webpack4-loader

callstack-bot · 2020-10-28T19:02:32Z

Hey @Anber, thank you for your pull request 🤗.
The coverage report for this branch can be viewed here.

satya164

We also might want to configure paths in our tsconfig.json so that typescript uses the source files when typechecking:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@linaria/*": ["./packages/*/src"]
    },
    "composite": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "esModuleInterop": true,
    "importsNotUsedAsValues": "error",
    "forceConsistentCasingInFileNames": true,
    "jsx": "react",
    "lib": ["esnext", "dom"],
    "module": "esnext",
    "moduleResolution": "node",
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "noImplicitUseStrict": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "resolveJsonModule": true,
    "strict": true,
    "target": "esnext"
  }
}

Though I think we'd need separate build configs for TS in individual packages if we do it:

{
  "extends": "./tsconfig",
  "compilerOptions": {
    "paths": {}
  }
}

docs/CONFIGURATION.md

package.json

satya164 · 2020-10-29T11:24:57Z

package.json

@@ -66,80 +65,41 @@
    "@types/debug": "^4.1.5",
    "@types/dedent": "^0.7.0",
    "@types/enhanced-resolve": "^3.0.6",


can we move type dependencies to the relevant packages which need them? e.g. to the webpack loader for enahanced resolve

Lerna suggests keeping dev dependencies on the top level, but it makes sense only if a dependency is used in 2+ packages. However, it has automatically collected deps from all packages :)

Oops. Forgot to clear that mess.

I guess by dev deps it means tooling like esint prettier etc. otherwise it's strange to have a dependency in one place and the type that complements it in a another place.

It suggests it mostly because of, in that case, it is easier to maintain deps versions between packages.

imo it's harder to maintain when you have one dependency in a package, and it's corresponding type in another place. when you change version of the package, you also need to remember to change the type to the corresponding version in a totally different place.

I definitely agree that @types should be in the same package.json as the dependencies, but what do you think about @babel-packages? They are using in almost all packages and I think it would be better to keep them in the root package.json

packages/babel/tsconfig.json

Anber · 2020-10-30T10:29:36Z

Hi @satya164!
I hope I got it right :)

thymikee · 2020-10-30T10:39:05Z

packages/cli/tsconfig.json

+{
+  "extends": "../../tsconfig.json",
+  "compilerOptions": {
+    "paths": {}


If a package references other internal package, it's good to set project references as well to provide deterministic builds: https://www.typescriptlang.org/docs/handbook/project-references.html. We use this at Jest monorepo

Is it really needed if we don't use tsc for building? Lerna itself checks the usages and provides deterministic builds.

if we don't use tsc for building

we'd still need to use tsc for building type definitions

Yeah, but it's also called by Lerna in a predefined order.

Seems like https://www.npmjs.com/package/@azu/lerna-to-typescript-project-references can do it automatically. Maybe just add it to prepare step?

package.json

jest.config.js

Anber · 2020-10-30T15:14:38Z

I'm ready for the next wave! :)

Anber · 2020-10-30T15:23:13Z

Oh… well. Something went wrong with references.

thymikee

🚀

antitoxic · 2020-11-13T16:53:10Z

👋 Hey @Anber what the status of that split? I see the webpack docs https://github.com/callstack/linaria/blob/master/docs/BUNDLERS_INTEGRATION.md#webpack refer to A non-existing package called @linaria/webpack-loader.

After some digging in npm I can find @linaria/webpack4-loader, but trying to set this up is blowing up with some babel duplicate plugins errors.

Anber · 2020-11-15T15:27:29Z

Hi @antitoxic

It's still in the beta. @linaria/webpack-loader is reserved for webpack 4/5 loader and will be released later this month.

trying to set this up is blowing up with some babel duplicate plugins errors.
It should work. Could you please create an issue with details?

Anber added 4 commits Oct 28, 2020

refactor: split one linaria package into multiple @linaria/*

3222d89

chore: an attempt to fix test coverage and the website

4bef70a

chore: second attempt to fix the website and test coverage

da43f8e

chore: third attempt to fix the website

5b09c0b

Anber mentioned this pull request Oct 28, 2020

Webpack 5 support #681

Closed

satya164 reviewed Oct 29, 2020

View changes

fix: post-review fixes

bb87088

thymikee reviewed Oct 30, 2020

View changes

package.json Outdated Show resolved Hide resolved

thymikee reviewed Oct 30, 2020

View changes

package.json Show resolved Hide resolved

thymikee reviewed Oct 30, 2020

View changes

jest.config.js Outdated Show resolved Hide resolved

Anber added 4 commits Oct 30, 2020

chore: try to clean mess in dependencies

0b13b0b

chore: watch task

ab50e63

chore: remove useless options from jest config

71c391c

chore: typescript references

f49d409

Anber added 2 commits Oct 31, 2020

chore: fix incremental build

ddc358b

fix: backward compatibility with 2.0

c5a9ff8

thymikee approved these changes Nov 7, 2020

View changes

Anber merged commit d0430f3 into master Nov 7, 2020
8 checks passed

Anber deleted the monorepo branch Nov 15, 2020

callstack / linaria Public

refactor: split one `linaria` package into multiple `@linaria/*` #687

refactor: split one `linaria` package into multiple `@linaria/*` #687

Anber commented Oct 28, 2020 •

edited by thymikee

callstack-bot commented Oct 28, 2020 •

edited

satya164 left a comment

satya164 Oct 29, 2020

Anber Oct 30, 2020

Anber Oct 30, 2020

satya164 Oct 30, 2020

Anber Oct 30, 2020

satya164 Oct 30, 2020

Anber Oct 30, 2020

Anber commented Oct 30, 2020

thymikee Oct 30, 2020

Anber Oct 30, 2020

satya164 Oct 30, 2020 •

edited

Anber Oct 30, 2020

Anber Oct 30, 2020

Anber commented Oct 30, 2020

Anber commented Oct 30, 2020

thymikee left a comment

antitoxic commented Nov 13, 2020

Anber commented Nov 15, 2020

callstack / linaria Public

refactor: split one linaria package into multiple @linaria/* #687

refactor: split one linaria package into multiple @linaria/* #687

Conversation

Anber commented Oct 28, 2020 • edited by thymikee

Motivation

Summary

callstack-bot commented Oct 28, 2020 • edited

satya164 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Anber commented Oct 30, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

satya164 Oct 30, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Anber commented Oct 30, 2020

Anber commented Oct 30, 2020

thymikee left a comment

antitoxic commented Nov 13, 2020

Anber commented Nov 15, 2020

refactor: split one `linaria` package into multiple `@linaria/*` #687

refactor: split one `linaria` package into multiple `@linaria/*` #687

Anber commented Oct 28, 2020 •

edited by thymikee

callstack-bot commented Oct 28, 2020 •

edited

satya164 Oct 30, 2020 •

edited