refactor: split one linaria package into multiple @linaria/*
#687
Conversation
There was a problem hiding this comment.
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": {}
}
}
package.json
Outdated
| @@ -66,80 +65,41 @@ | |||
| "@types/debug": "^4.1.5", | |||
| "@types/dedent": "^0.7.0", | |||
| "@types/enhanced-resolve": "^3.0.6", | |||
There was a problem hiding this comment.
can we move type dependencies to the relevant packages which need them? e.g. to the webpack loader for enahanced resolve
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
Oops. Forgot to clear that mess.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
It suggests it mostly because of, in that case, it is easier to maintain deps versions between packages.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
|
Hi @satya164! |
packages/cli/tsconfig.json
Outdated
| { | ||
| "extends": "../../tsconfig.json", | ||
| "compilerOptions": { | ||
| "paths": {} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Is it really needed if we don't use tsc for building? Lerna itself checks the usages and provides deterministic builds.
There was a problem hiding this comment.
if we don't use tsc for building
we'd still need to use tsc for building type definitions
There was a problem hiding this comment.
Yeah, but it's also called by Lerna in a predefined order.
There was a problem hiding this comment.
Seems like https://www.npmjs.com/package/@azu/lerna-to-typescript-project-references can do it automatically. Maybe just add it to prepare step?
|
I'm ready for the next wave! :) |
|
Oh… well. Something went wrong with references. |
|
👋 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 After some digging in npm I can find |
|
Hi @antitoxic It's still in the beta.
|
Motivation
Closes #413
Summary
The list of packages: