Add remark-flexible-containers to list of plugins

[talatkuyuk]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)
• If applicable, I’ve added docs and tests

Description of changes

Added a new plugin remark-flexible-containers to list of plugins

https://github.com/ipikuka/remark-flexible-containers
https://www.npmjs.com/package/remark-flexible-containers

I've taken the experience which I got during development of my previous plugin remark-flexible-code-titles into considerations.

[codecov-commenter]

Codecov Report

Merging #1112 (4d9d95a) into main (20e7543) will not change coverage.
The diff coverage is n/a.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1112   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        10           
  Lines          906       906           
=========================================
  Hits           906       906           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 20e7543...4d9d95a. Read the comment docs.

[remcohaszing]

Thanks!

A couple of hints for your package:

1. You build a CJS package, but you have ESM-only dependencies. This means your package doesn’t work with CJS. I suggest to remove CJS support altogether
2. I recommend using the prepack script over prepare.
3. You can use prettier --write . to format all files in a directory. Use .prettierignore to ignore certain files. This way the CLI and your editor use the same settings.
4. The same as Prettier goes for ESLint. Add overrides to make ESLint understand extensions.
5. .eslintrc without an extension is deprecated.

[talatkuyuk]

Hi @remcohaszing, thanks for the hints, I've learnt a lot.

I implemented all in v1.0.1 and v1.0.2

Could you check the .eslintrc.json whether I understand the issue about overrides, please.

[remcohaszing]

You can move everything that’s specific into the override. Also I don’t see the need to specify the src and tests directories explicitly. So it would become something like this (I didn’t test it in your repo):

{
  "root": true,
  "extends": [
    "prettier",
    "plugin:prettier/recommended",
    "eslint:recommended"
  ],
  "plugins": ["@typescript-eslint", "prettier"],
  "overrides": [
    {
      "files": ["**/*.ts"],
      "parser": "@typescript-eslint/parser",
      "extends": [
        "plugin:@typescript-eslint/eslint-recommended",
        "plugin:@typescript-eslint/recommended"
      ],
      "rules": {
        "@typescript-eslint/no-non-null-assertion": "off",
        "@typescript-eslint/ban-ts-comment": "off",
        "@typescript-eslint/no-explicit-any": "off"
      }
    }
  ],
  "env": {
    "node": true
  }
}

[talatkuyuk]

I got it for the issue about overrides. Thanks.
💚 I made the change in the eslint config without problem.

If you have time, could you also have a look at the package.json and tsconfig.json whether the package is for ESM only, now.

In typescript config, I was using module: "NodeNext", I converted it into "ES2020" and made "moduleResolution" appropriate. I have also a concern about keeping the main property while there is exports which takes precedence over main in package.json.

[talatkuyuk]

Waiting your comments, is there anything that is advisable in the code ?

[remcohaszing]

Nowadays the most correct module option is node16. This also configures moduleResolution and allowSyntheticDefaultImports correctly, so you don’t have to.

You’re also emitting type declarations in a directory different from the JavaScript output. As a result, you need to specify both types for users using the legacy node module resolution, and exports/types for people using the more correct node16 resolution. This can all be avoided by emitting the type definitions alongside the JavaScript output. So it becomes something like this:

  {
    "include": ["src/**/*"],
    "compilerOptions": {
      "target": "ES2020",
      "lib": ["ES2020"],
+     "module": "node16",
-     "module": "ES2020",
-     "moduleResolution": "node",
      "strict": true,
      "declaration": true,
-     "declarationDir": "./dist/types",
-     "allowSyntheticDefaultImports": true,
      "sourceMap": true,
      "noImplicitReturns": true,
      "outDir": "dist/esm",
      "types": ["node", "jest"]
    }
  }

And in package.json you would have to either remove types, or change it accordingly.

The main field in package.json may still be used by legacy tools. You can remove it if you want, but it doesn’t hurt to keep it. I have no strong feelings about this.

[wooorm]

Thanks @talatkuyuk!