Reduce Boilerplate #22640
Replies: 7 comments
-
For example, the contents of the default const { getJestProjects } = require("@nrwl/jest")
import * as path from "path"
import type { Config } from "jest"
import { defaults as tsPreset } from "ts-jest/presets"
export const jestConfigNode = (props: { projectDir: string }): Config => {
const downPath = path.relative(__dirname, props.projectDir)
const upPath = path.relative(props.projectDir, __dirname)
const project = require(path.join(props.projectDir, "project.json"))
return {
coverageDirectory: path.join(upPath, "coverage", downPath),
displayName: project.name,
globals: { "ts-jest": { tsconfig: "<rootDir>/tsconfig.test.json" } },
preset: path.join(upPath, "jest.preset.js"),
testEnvironment: "node",
transform: tsPreset.transform,
}
}
export default {
projects: getJestProjects(),
} Then your per-lib import { jestConfigNode } from "../../jest.config"
export default jestConfigNode({ projectDir: __dirname }) Would be awesome if Nx could help us do this sort of thing to keep our repos full of redundant noise. |
Beta Was this translation helpful? Give feedback.
-
Hello! Could you assign me this issue? |
Beta Was this translation helpful? Give feedback.
-
I cannot approve more this issue, I am surprised there is not more people on it (for developers around me this is the issue # 1 with NX), maybe is there an other open issue about this concern? The management of configuration files in NX could be much DRYer: for each lib I get 8 more config files for often just a couple of source files. That makes navigation between source files much harder. Moreover when there is some specific things to add in a configuration file for a given kind of lib (e.g. a new eslint rule for an angular lib), it is painful to keep all these configuration files synced together. It'd be awesome to be able to define config file templates for each kind of lib (angular, react, nest, pure ts, etc...) at the root of the workspace and just refer to it in each project (in the |
Beta Was this translation helpful? Give feedback.
-
I'm also suprised that there aren't more people advocating for this. I think it would be great if there was an option especially when generating apps and libraries where you can opt-in to generating files like: |
Beta Was this translation helpful? Give feedback.
-
It's possible we can address this for I'll move this over to a discussion so we can continue the broad discussion but I think it would be good to breakout this discussion into dedicated threads for each config file. They all serve different purposes and have their own considerations. |
Beta Was this translation helpful? Give feedback.
-
Hi there, I had also initiated a discussion here: #22097 We're currently trying to switch to 20% apps / 80% libs architecture as recommended by NX, but making a lib adds 6 config files each time, it's pretty boilerplate indeed ^^. |
Beta Was this translation helpful? Give feedback.
-
I guess a lot of people would benefit from that as it also makes NX a better option to choose in the first place. We want to migrate a relatively large codebase to small libs, to profit from incremental builds. But at the moment it just makes it so unnecessary complex to add libs via the default generators. Like, why do I need to have 50 different config files if they all include the same data? |
Beta Was this translation helpful? Give feedback.
-
Is there anything that can be done to reduce the amount of boilerplate in in a Nx repo?
Generators are helpful, but you're still stuck with an annoying large number of duplicate files in every single lib in your project (
.babel*
,.eslint*
,jest.*
,tsconfig.*
, etc) that distract from what's actually going on.I know this is a symptom of the broader JS ecosystem, but wonder if Nx can do anything here to improve the developer experience.
Beta Was this translation helpful? Give feedback.
All reactions