From c07ea0fa7140b83fe8ef13c49afe8ef838034686 Mon Sep 17 00:00:00 2001 From: prisis Date: Mon, 16 Sep 2024 00:18:23 +0200 Subject: [PATCH] fix: added Security Policy, added test run on release, updated readme --- .github/workflows/semantic-release.yml | 4 +- SECURITY.md | 69 +++++++++++++++++++ packages/packem/README.md | 49 ++++++++++++- .../__tests__/intigration/css-modules.test.ts | 2 +- .../__tests__/intigration/typescript.test.ts | 2 +- 5 files changed, 121 insertions(+), 5 deletions(-) create mode 100644 SECURITY.md diff --git a/.github/workflows/semantic-release.yml b/.github/workflows/semantic-release.yml index 26af5c113..92c5c9189 100644 --- a/.github/workflows/semantic-release.yml +++ b/.github/workflows/semantic-release.yml @@ -63,8 +63,8 @@ jobs: - name: "Build Production" run: "pnpm run build:packages:prod" -# - name: "test and coverage" -# run: "pnpm run test:coverage" + - name: "test and coverage" + run: "pnpm run test:coverage" - name: "Prepare nx cache" shell: "bash" diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000..692613fb3 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,69 @@ + + +# Security Policy + +Security is core to our values, and we value the input of hackers acting in good faith to help us maintain a high standard for the security and privacy for our users. +This includes encouraging responsible vulnerability research and disclosure. +This policy sets out our definition of good faith in the context of finding and reporting vulnerabilities, as well as what you can expect from us in return. + +## Supported Versions + +Use this section to tell people about which versions of your project are +currently being supported with security updates. + +| Version | Supported | +|---------| ------------------ | +| 1.0.x | :white_check_mark: | + +## Expectations + +When working with us according to this policy, you can expect us to: +- Extend Safe Harbor (see below) for your vulnerability research that is related to this policy; +- Work with you to understand and validate your report +- Work to remediate discovered vulnerabilities in a timely manner; and +- Recognize your contribution to improving our security if you are the first to report a unique vulnerability, and your report triggers a code or configuration change. + +## Safe Harbor + +When conducting vulnerability research according to this policy, we consider this research to be: +- Authorized in accordance with the law, and we will not initiate or support legal action against you for accidental, good faith violations of this policy; +- Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls; +- Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy; +- Lawful, helpful to the overall security of the Internet, and conducted in good faith. + +You are expected, as always, to comply with all applicable laws. + +If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further. + +## Ground Rules + +To encourage vulnerability research and to avoid any confusion between good-faith hacking and malicious attack, we ask that you: +- Play by the rules. This includes following this policy, as well as any other relevant agreements. If there is any inconsistency between this policy and any other relevant terms, the terms of this policy will prevail. +- Report any vulnerability you have discovered promptly. +- Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience. +- Use only the Official Channels to discuss vulnerability information with us. +- Keep the details of any discovered vulnerabilities confidential until they are fixed, according to the Disclosure Terms in this policy. +- Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope. Systems currently considered in-scope are the official demonstration/test servers provided by the Visulima development team. +- If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept; and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information. +- You should only interact with test accounts you own or with explicit permission from the account holder. +- Do not engage in extortion. + +## Disclosure Terms + +The vulnerability is kept private until a majority of instances have updated to a safe version or applied a hotfix. The Visulima development team coordinates efforts to update once the patch is issued. + +## Official Channels + +To help us receive vulnerability submissions we use the following official reporting channel: + +- security@visulima.com +- [GitHub advisories](https://github.com/visulima/visulima/security/advisories/new) + +If you think you have found a vulnerability, please include the following details with your report and be as descriptive as possible: +- The location and nature of the vulnerability, +- A detailed description of the steps required to reproduce the vulnerability (screenshots, compressed screen recordings, and proof-of-concept scripts are all helpful), and +- Your name/handle and a link for recognition. + +If you would like to encrypt the information, please use our GPG key. + +We may modify the terms of this program or terminate this program at any time. We will not apply any changes we make to these program terms retroactively. diff --git a/packages/packem/README.md b/packages/packem/README.md index 335884878..ca94989ae 100644 --- a/packages/packem/README.md +++ b/packages/packem/README.md @@ -48,6 +48,9 @@ It uses the `exports` configuration in `package.json` and recognizes entry file - ✅ Supports react server and client components - ✅ Supports shared modules - ✅ Supports dynamic import +- ✅ Supports `tsconfig.json` paths and `package.json` imports resolution +- ✅ ESM ⇄ CJS interoperability +- ✅ Supports isolated declaration types (experimental) And more... @@ -380,7 +383,7 @@ console.log(text); // "Hello World" #### Visualize Bundle Makeup -Use the `--visualize` flag to generate a `stats.html` file at build time, showing the makeup of your bundle. +Use the `--visualize` flag to generate a `packem-bundle-analyze.html` file at build time, showing the makeup of your bundle. #### Building Module Workers (Experimental) (WIP) @@ -394,6 +397,50 @@ worker = new Worker('./worker.js', { type: 'module' }); #### CSS and CSS Modules (Coming Soon) +### Aliases +Aliases can be configured in the [import map](https://nodejs.org/api/packages.html#imports), defined in `package.json#imports`. + +For native Node.js import mapping, all entries must be prefixed with `#` to indicate an internal [subpath import](https://nodejs.org/api/packages.html#subpath-imports). `Packem` takes advantage of this behavior to define entries that are _not prefixed_ with `#` as an alias. + +Native Node.js import mapping supports conditional imports (eg. resolving different paths for Node.js and browser), but `packem` does not. + +> ⚠️ Aliases are not supported in type declaration generation. If you need type support, do not use aliases. + +```json5 +{ + // ... + + "imports": { + // Mapping '~utils' to './src/utils.js' + "~utils": "./src/utils.js", + + // Native Node.js import mapping (can't reference ./src) + "#internal-package": "./vendors/package/index.js", + } +} +``` + +### ESM ⇄ CJS interoperability + +Node.js ESM offers [interoperability with CommonJS](https://nodejs.org/api/esm.html#interoperability-with-commonjs) via [static analysis](https://github.com/nodejs/cjs-module-lexer). However, not all bundlers compile ESM to CJS syntax in a way that is statically analyzable. + +Because `packem` uses Rollup, it's able to produce CJS modules that are minimal and interoperable with Node.js ESM. + +This means you can technically output in CommonJS to get ESM and CommonJS support. + +#### `require()` in ESM +Sometimes it's useful to use `require()` or `require.resolve()` in ESM. ESM code that uses `require()` can be seamlessly compiled to CommonJS, but when compiling to ESM, Node.js will error because `require` doesn't exist in the module scope. + +When compiling to ESM, `packem` detects `require()` usages and shims it with [`createRequire(import.meta.url)`](https://nodejs.org/api/module.html#modulecreaterequirefilename). + +### Environment variables +Pass in compile-time environment variables with the `--env` flag. + +This will replace all instances of `process.env.NODE_ENV` with `'production'` and remove unused code: +```sh +packem build --env.NODE_ENV=production +``` + ## Validating `Packem` validates your `package.json` file and checks if all fields are configured correctly, that are needed to publish your package. diff --git a/packages/packem/__tests__/intigration/css-modules.test.ts b/packages/packem/__tests__/intigration/css-modules.test.ts index a0d606615..261b2a829 100644 --- a/packages/packem/__tests__/intigration/css-modules.test.ts +++ b/packages/packem/__tests__/intigration/css-modules.test.ts @@ -6,7 +6,7 @@ import { afterEach, beforeEach, describe, expect, it } from "vitest"; import { createPackageJson, createPackemConfig, execPackemSync } from "../helpers"; -describe("packem css modules", () => { +describe.todo("packem css modules", () => { let temporaryDirectoryPath: string; beforeEach(async () => { diff --git a/packages/packem/__tests__/intigration/typescript.test.ts b/packages/packem/__tests__/intigration/typescript.test.ts index 95378a654..535a34b5b 100644 --- a/packages/packem/__tests__/intigration/typescript.test.ts +++ b/packages/packem/__tests__/intigration/typescript.test.ts @@ -308,7 +308,6 @@ console.log(1); writeFileSync(`${temporaryDirectoryPath}/tt/a/aa.ts`, "export const a = 1;"); writeFileSync(`${temporaryDirectoryPath}/tt/b/bb.ts`, 'import { a } from "./aa";\nnconsole.log(a);\n\nexport const b = 2;'); - await installPackage(temporaryDirectoryPath, "typescript"); createTsConfig(temporaryDirectoryPath, { compilerOptions: { rootDir: ".", @@ -320,6 +319,7 @@ console.log(1); typescript: "*", }, main: "./dist/index.cjs", + module: "./dist/index.mjs", }); await createPackemConfig(temporaryDirectoryPath, {});