According to TSC documentation, the jsx field is only related to emitting code.

As we don't use TSC to emit code, we should remove the jsx field.

Controls how JSX constructs are emitted in JavaScript files. This only affects output of JS files that started in .tsx files.

react: Emit .js files with JSX changed to the equivalent React.createElement calls
react-jsx: Emit .js files with the JSX changed to _jsx calls
react-jsxdev: Emit .js files with the JSX changed to _jsx calls
preserve: Emit .jsx files with the JSX unchanged
react-native: Emit .js files with the JSX unchanged

Source: https://www.typescriptlang.org/tsconfig#jsx

Should extends monorepo-root instead.

Hard-coding a publicPath value into a bundle is not very robust, as it makes the page fail to load scripts whenever the publicPath value is different from the URL the page is running on.

Setting it to "auto" will make Webpack use document.currentScript to resolve scripts in the bundle, which is useful in micro-frontend setups, and will work when the page is hosted on any URL.

We could define a list of public path and create a different build for each environemnts, but using "auto" is simpler and lets us re-use a single configuration across environments.

The web configs are going to be used by existing project, we could accomodate them with a more detailed installation procedure

I believe that we now know enough about tsup to add a shared config to this project.

The shared config should strictly target TS libraries. We have a few examples in squide.

I really like tsup's native defineConfig function. I believe we should develop something around this.

We could either export our own defineConfig function pre-configured with our defaults or a JSON config that the end user would have to pass to tsup's native defineConfig function.

Source code for Next.js: https://github.com/vercel/next.js/blob/canary/packages/next/src/build/webpack-config.ts#L1810

What's interesting are:

• The cacheDir option for the TerserPlugin
• The parallel and swcMinify option of the TerserPlugin
• Using CssMinimizerPlugin for CSS compression

• Use Retype platform

It is quite confusing that some packages are named "config" while other "configs". We wish to normalize everything to "configs".

The stylelint package is excluded from this issue as it will be refactored into a plugin.

tsup configs should be provided by this monorepo as a standalone package.

The tsup CLI support TypeScript configuration file so maybe they don't required a transpilation before being packaged?

2 configs should be offered:

• dev with a config named dev.ts
• build with a config named build.ts

I really like tsup's native defineConfig function. I believe we should develop something around this.

We could either export our own defineConfig function pre-configured with our defaults or a JSON config that the end user would have to pass to tsup's native defineConfig function.

When configuring EsLint for the project and using @workleap/eslint-plugin, in the .eslintrc.json like this:

{
    "$schema": "https://json.schemastore.org/eslintrc",
    "root": true,
    "extends": "plugin:@workleap/web-application"
}

As it is documented here. But I get this error from EsLint for each file:

ESLint: Definition for rule '@workleap/strict-css-modules-names' was not found.(@workleap/strict-css-modules-names)

Some more information:

• Package manager: PNPM v8.4.0
• Node: v18.16.0
• EsLint: v8.40.0
• OS: Win 10

Sadly not all tools support ESM. Therefore, our eslint config should allow using CommonJS environment variables like module.

When I execute the following script: "eslint --ext .js,.ts,.tsx . --max-warnings=-1 --cache --cache-location node_modules/.cache/eslint" I get the following warning:

Warning: React version not specified in eslint-plugin-react settings. See https://github.com/jsx-eslint/eslint-plugin-react#configuration .

Since an .eslintignore file will always be added to projects using our ESLint configs, I suggest adding a section in the ESLint configs docs with the expected content of the .eslintignore file.

In some situations rounding rem values in CSS leads to non precise values in pixel.

When there's a need for a value with a .5px in rem the value is: 0.03125 which triggers a linting error, rounding to 0.03123 would compute a value of 0.5008px if 1 rem = 16px. This can lead to problematic values when dealing with line-height.

I just generated a Introduction.mdx file with storybook init, and the linting goes crazy in that file.

Add */snapshots/ to every documented ignore files

The package name in the readme no longer seems to correspond to the actual package in the repository.

The expected package name is @workleap/postcss-configs and the link is https://github.com/gsoft-inc/wl-web-configs/tree/main/packages/postcss-configs#workleappostcss-configs

Add https://github.com/arethetypeswrong/arethetypeswrong.github.io/tree/main/packages/cli to the projects

In packages/swc-configs/README.md, @types/jest is missing from dependency.

Without it, IDE is missing all Jest types and methods in .test.js[x] files.

clean, ``test and lint:types scripts should be handled by the monorepo root scripts instead of being delegated to packages.

Since PNPM is not hoisting packages, it would be expected to add jest and typescript as devDependencies to every package otherwise.

Furthermore, it's repetitive and can be avoided by using pnpm exec.

In the monorepo root scripts you could have:

• "test": "jest" and use filters when you want to filter to a specfic packages, file or test with either --ignoreProjects, --testNamePattern, --testPathIgnorePatterns or --testPathPattern
• "lint:types": "tsc",
• "clean": "pnpm -r --include-workspace-root --parallel exec pnpm dlx rimraf dist node_modules/.cache" and use PNPM filters when necessary to filter by project

Demand coming from slack:

Add eslint rules for stylistic rules, such as:

• no extra spacing
• extra line before if/for operators

The current documentation shows what to put in the config:

/** @type {import("postcss").Postcss} */
module.exports = {

module.exports is the CJS synthax. It should be

export default {

instead.

Slack demand from Pat

https://johnnyreilly.com/typescript-5-importsnotusedasvalues-error-eslint-consistent-type-imports

Related tweet: https://twitter.com/johnny_reilly/status/1656014914157256715?s=46&t=phHk4nAnKfwA1Cl1rTw3sQ

As part of our initiative to makes our apps accessible, we wish to automate as much markup validation as possible.

To help with that, we want to add https://www.npmjs.com/package/eslint-plugin-jsx-a11y to our default ESLint rule configurations.

When running pnpm audit. There is a package @babel/traverse that has a critical vulnerability. More info : GHSA-67hx-6x53-jw92
It's an indirect dependency I understand. So it can be fixed only when those dependecies update.

Since the packages are now transpiled with tsup, from my understanding their tsconfig.json files shouldn't include compilerOptions and exclude fields as those are managed by tsup.

In the core.ts file in the TS configs, I think declaration should be false by default as we never want to use tsc to emit declarations.

For a long time, when using CRA, if we had errors, it would stop the linting and only display the most recent error instead of listing them all.

In order to be able to see all the eslint errors in the dev server, we changed all our errors to warnings instead. This way eslint lists all the lint warning instead of only the first one.

Now that we are back to using eslint's cli, i don't think we should use "warn" anymore for our configs. We should extends eslint:recommended, and add our custom rules as errors

Asking in an issue since "discussion" are not configured for this repo.

Why does a TypeScript config for a web-application needs a baseUrl but others don't?

A library project

To prevent new projects from linting twice their codebase when using the TypeScript monorepo-root config, the documentation should mention that without an excluded it will happen.

The docs sample should probably exclude the package folder by default:

{
    "extends": "@workleap/typescript-configs/monorepo-root.json",
    "exclude": ["packages", "node_modules"]
}

Most project will probably get a TS18003 error with the exclusion thought. My current solution is to add an ignore-18003.ts file at the root of my monorepo.

Since we are enforcing the usage of ESM, all defaut TypeScript configurations should have allowImportingTsExtension set to true by default.

There are a few issue with this docs example for TypeScript monorepo config:

• Monorepo setup doesn't have a ./src folder at the root
• baseUrl is only needed when aliases are specified (should also be fixed for other TypeScript configs docs example)
• pretty sure node_modules folder is excluded by default

Since we are not expecting to transpile files with tsc, from what I experienced with my latest repo, all is needed in the tsconfig.json at the root is:

{
    "extends": "@workleap/typescript-configs/monorepo-root.json"
}

(It's probably similar for the other TypeScript config files as well)

Currently, using stylelint-configs with prettier =>3.0.0 causes the following error:

TypeError: prettier.resolveConfig.sync is not a function

The error seems to be caused by stylelint-prettier. They don't seems to have updated their package to support prettier v3.0.0 yet.

In the meantime, products should stay on prettier v2.8.8

Turns out that ESLint overrides doesn't seem to merge the env settings.

In core.ts we have:

    env: {
        es6: true,
        node: true,
        commonjs : true
    },

And in react.ts we have:

            env: {
                browser: true
            },

As a consumer, in my application, when using plugin:@workleap/web-application, the node settings is not true anymore.

There's usually a difference between the clean and the reset scripts as they fulfill different purpose.

clean is used to delete cache files, the dist folder and other similar artifacts while the reset script is used to clean but also reset the whole solutions by deleting the node_modules folder and the package manager .lock files.

It's an important distinct as deleting the node_modules folder everytime you to reset the package outputs (deleting the dist folder) is frustrating.

Adding a very simple CONTTRIBUTORS documentation would help to get future maintainers started.

• How to setup the project
• How to start developping
• How to release
• Anything specific that a maintainer should be aware of

ESLint and TypeScript configurations are both designed "by project type" and are both composed of "parts".

Therefore, both should use the same folders structure. IMO, the TypeScript should be updated to match the ESLint project.

There is no mention of .stylelintignore in @workleap/stylelint-config README.md, do we need this file to be sure StyleLint doesn't interfere with EsLint?

As a note also, it is worth mentioning that .stylelintignore acts differently than normal .ignore files as of:

*
!**/*.css

will not work and will just ignore everything.

The test RegEx used by Webpack are too lenient and can target the wrong file extensions:

See: https://github.com/gsoft-inc/wl-web-configs/blob/main/packages/webpack-configs/src/dev.ts

{
    test: /\.(js|jsx|ts|tsx)/i,
    exclude: /node_modules/,
    loader: require.resolve("swc-loader"),
    options: trySetSwcFastRefresh(swcConfig, fastRefresh !== false)
},

The ReGex /\.(js|jsx|ts|tsx)/i is missing the end-of-string $ token.

Because of this, the ReGex incorrectly matches .json files, which breaks json-loading in Webpack.

Using tsup to build our app, we see a huge memory leak in the process.

Locally, the node.js JavaScript Runtime gets increasingly bigger until it reaches 4GB of Memory, and then it crashed. The crash occurs in 30sec to 1 minute after launching the app, and doing nothing at all with it.

In the CI pipeline, we increased the max memory size to 8GB using NODE_OPTIONS: --max_old_space_size=8192, which did the job...

We have been experimenting with using the tsup --experimental-dts to replace the normal --dts. So far, the app memory is stable around 600MB locally, and build 3 times faster in the CI pipeline (30s, down from 1min30s).

So far, no issues with the new tsup config. We will continue to monitor the effects of the new config.

I have a regular js file and I keep getting type error from TS.

The file doesn't have a @ts-check at the top so I don't see any reason why TS would try to validate that JS file.

The way our per-project-type configs works, the config files consuming them will always be considered as a root config file.

Therefore, docs examples should include root: true.

Since we only lint with tsc and use tsup to transpile code, I don't think we need the target and sourceMaps fields in our TS configs as they are strictly related to transpilation.

Therefore, we should remove them.

I wonder whether we should add or not minify: true to our tsup config?

Most libraries we used ship unminified. It does help because it's easy to open the source code and understand how it works and even add debugging instructions.

What do you think?

The downside is that the applications build scripts will have to minify the code which might increase the build time. Still, I am not sure if application build scripts minification process ignore "already minified" libraries.

https://github.com/webpro/knip

Similarly to our other tools, tsup should have it's own tsup.config.js or tsup.config.json file instead of being configured in the package.json file.

Furthermore, since we are using PNPM, devDependencies should be declared in every package instead of the monorepo root. tsup dependency is currently problematic.

The TypeScript's package readme has issues

@workleap/library/build.json

should read

@workleap/typescript-configs/library/build.json