kablamooss / kerosene Goto Github PK

We need some documentation explaining the project as a whole and how to use parts.

We also need something like JSDoc to generate documentation for all the functions that we export.

Finally, this needs to be hosted somewhere.

Because we default to false for visibility, and then immediately trigger the effect, the component will double render unnecessarily when useState === true. We should default this state value to !(document.hidden ?? false) instead.

Related issue: jestjs/jest#11511

As a workaround we can import { setImmediate } from "timers"; but it may also be worth investigating other ways to enqueue macro tasks.

JSDoc remains in the transpiled output code, but the generated *.d.ts files seem to be unintentionally stripping JSDoc.

Following on from #66

Not everyone uses data-test-id, so it would be good to configure your cypress with your preferred convention, ie data-testid. And have the cy.testId command know which one you're using.

Look at adding additional rules to enforce conventions, including:

• @typescript-eslint/naming-convention

In packages/kerosense/src/index.ts, we currently do

import * as arrayUtils from './array';
import * as stringUtils from './string';

export default {
  ...arrayUtils,
  ...stringUtils,
};

A single default export here is not tree-shakeable, because it is not statically analysable. We should instead export each method individually. To avoid repetitiveness, we could use a similar build system to lodash where the JSDoc of each method is used to automatically generate all the import/export statements in the output and group methods into categories (array, string, etc.).

We also currently just produce CommonJS output which cannot be tree-shaken either. The solution to this would be to produce multiple output files, with the "main" field in package.json pointing to the CommonJS build and the "module" field used by bundling tools pointing to an ES modules build.

We also have a dependency on lodash where we are not currently using cherry-picked method imports (like import identity from "lodash/identity";). I would suggest that either we use cherry-picked imports ourselves, or instead build with @babel/preset-typescript so that we may use babel-plugin-lodash which will do this for us.

When a push to master is made, attempt to publish to npm.

You are required to increment the version by hand (or in a PR) as a means of change control, to trigger a new deployment.

This means we can run master as trunk-based-development, and control releases by increment versions in package.json.

A PR is incoming that will add some eslint rules themselves, along with a small config to enable them.

We should also consider creating one or more eslint configurations we can use in our projects, that we could pull in via:

module.exports = {
  plugins: ["@kablamo"],
  extends: [
    "plugin:@kablamo/recommended",
    "plugin:@kablamo/react",
  ]
};

Node.js 8.x is EOL as of 31/12/2019, and 13.x is now the current release, as per https://github.com/nodejs/Release

Is there a way to pull in all current/LTS versions rather than manually specifying these versions?

?

Run builds, and tests on PR's:

• run tests
• run coverage.

     "prebuild": "yarn workspace @kablamo/kerosene run build", 

is required because kerosene-ui depends on kerosene.

Is there a better way to do this? We should be able to keep the build system to a single command.

Looks like .dist/es/lib folders are being included in test coverage reports erroneously.