💻 a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Keep the package loadable on node 12, and enforce it (#216) * Emit es2019 so the built output parses on node 12 engines has claimed node >= 12 all along, but nothing enforced it, and a tsconfig target of es2020 let a nullish coalescing operator reach dist as written. Node 12 cannot parse it, so requiring the package threw a SyntaxError at load: not a broken code path but a package that could not be loaded at all on the oldest runtime it claims. Lowering the target to es2019 makes tsc downlevel that operator and refuse any newer syntax at compile time, so the emitted output cannot drift past node 12 again without a build failure. lib stays at es2020 for the bigint types; every es2020 library addition already exists in node 12. The two BigInt literals become BigInt() calls, which is what a target below es2020 requires and what the surrounding code already does. The dev toolchain cannot run on node 12 to catch this: mocha 11, chai 6, tsx and c8 all require node 18 or newer, mocha's own entry point uses node: prefixed requires, and node 12 ships npm 6.14 which cannot read a lockfileVersion 3 lockfile. A matrix entry would fail on the toolchain and report nothing about the library. The new job instead builds dist on a current node and then requires it under node 12, which is what a consumer on an old runtime does and the only place a regression in emitted syntax shows up. The smoke test covers both address families, subnets, BigInt round trips, byte arrays and fromURL, the site of the operator in question. * Format the repository with prettier Seventeen files had drifted from prettier's output, which made a formatting warning on a touched file indistinguishable from one already there and cost time on the previous commit deciding which was which. Everything prettier covers now matches it. Two categories are excluded rather than reformatted. The vendored InterMapper address fixtures stay in the shape they arrived in so they remain comparable against their source. Build output is listed as well, so a local build or coverage run cannot make a check of the whole tree fail on files that are not in the repository. The example block at the top of the README aligns its result comments into a column, which prettier would collapse, so the template marks that one fence prettier-ignore. The marker is an HTML comment and flows through into the generated README, where it does not render. * Clear the eslint findings across src, test and scripts Nothing linted the TypeScript: eslint's default extension list is .js alone, so `eslint .` only ever saw the config file itself and reported clean while seventeen findings sat in the library and its tests. They are all resolved here so the rules can be enforced. no-bitwise is off rather than suppressed. Masks, prefix lengths and the NAT64 and Teredo encodings are defined in terms of shifts and xors, so the rule fires on correct code throughout: nine inline suppressions had accumulated against six live findings, and one suppression had drifted onto the line after the operator it was meant to cover. The suppressions are gone with it. The two ignored catch bindings become optional catch bindings, which es2019 allows and node 12 supports. The NAT64 bit assembly becomes an array joined at the end, so the reserved u octet can be named instead of appearing as a bare string in the middle of a concatenation. A shadowed path in the readme builder and a shadowed v6 in a test are renamed for what they hold, and the closure returned by isCorrect gets a name. Build scripts are allowed to write to stdout, which is how they report progress. * Check formatting and lint in CI and from a pre-commit hook There was no lint script and no CI step for one, so formatting drift and lint findings only surfaced when someone happened to run the tools by hand. CI now runs both against the whole tree, with eslint pointed at .ts as well as .js and warnings treated as failures so nothing accumulates below the threshold. The check reports rather than corrects. Correcting in CI means granting a workflow write access to the repository, and a token-authored commit does not retrigger workflows, so a pull request would end up with its head unchecked; fork pull requests would still need fixing by hand either way. The same check therefore runs from a pre-commit hook, installed by pointing core.hooksPath at a committed hooks directory, so a violation is caught before it is pushed and `npm run lint:fix` corrects everything mechanical. Extending airbnb-base rather than airbnb drops eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11y from a library with no react in it, taking 377 lines out of the lockfile and with them the warning the react plugin printed on every run because it could not detect a version. The rules that remain are the same ones; airbnb adds only react and accessibility rules on top of that base. * Check that the generated README is current in CI The API reference in the README is generated from the source, including the line numbers its per-method source links point at, so any change under src leaves it stale until `npm run docs` is run again. That happened twice while writing the previous commits and was only noticed by hand. CI now regenerates it and fails if the result differs from what is committed. | 30 天前 | |
Keep the package loadable on node 12, and enforce it (#216) * Emit es2019 so the built output parses on node 12 engines has claimed node >= 12 all along, but nothing enforced it, and a tsconfig target of es2020 let a nullish coalescing operator reach dist as written. Node 12 cannot parse it, so requiring the package threw a SyntaxError at load: not a broken code path but a package that could not be loaded at all on the oldest runtime it claims. Lowering the target to es2019 makes tsc downlevel that operator and refuse any newer syntax at compile time, so the emitted output cannot drift past node 12 again without a build failure. lib stays at es2020 for the bigint types; every es2020 library addition already exists in node 12. The two BigInt literals become BigInt() calls, which is what a target below es2020 requires and what the surrounding code already does. The dev toolchain cannot run on node 12 to catch this: mocha 11, chai 6, tsx and c8 all require node 18 or newer, mocha's own entry point uses node: prefixed requires, and node 12 ships npm 6.14 which cannot read a lockfileVersion 3 lockfile. A matrix entry would fail on the toolchain and report nothing about the library. The new job instead builds dist on a current node and then requires it under node 12, which is what a consumer on an old runtime does and the only place a regression in emitted syntax shows up. The smoke test covers both address families, subnets, BigInt round trips, byte arrays and fromURL, the site of the operator in question. * Format the repository with prettier Seventeen files had drifted from prettier's output, which made a formatting warning on a touched file indistinguishable from one already there and cost time on the previous commit deciding which was which. Everything prettier covers now matches it. Two categories are excluded rather than reformatted. The vendored InterMapper address fixtures stay in the shape they arrived in so they remain comparable against their source. Build output is listed as well, so a local build or coverage run cannot make a check of the whole tree fail on files that are not in the repository. The example block at the top of the README aligns its result comments into a column, which prettier would collapse, so the template marks that one fence prettier-ignore. The marker is an HTML comment and flows through into the generated README, where it does not render. * Clear the eslint findings across src, test and scripts Nothing linted the TypeScript: eslint's default extension list is .js alone, so `eslint .` only ever saw the config file itself and reported clean while seventeen findings sat in the library and its tests. They are all resolved here so the rules can be enforced. no-bitwise is off rather than suppressed. Masks, prefix lengths and the NAT64 and Teredo encodings are defined in terms of shifts and xors, so the rule fires on correct code throughout: nine inline suppressions had accumulated against six live findings, and one suppression had drifted onto the line after the operator it was meant to cover. The suppressions are gone with it. The two ignored catch bindings become optional catch bindings, which es2019 allows and node 12 supports. The NAT64 bit assembly becomes an array joined at the end, so the reserved u octet can be named instead of appearing as a bare string in the middle of a concatenation. A shadowed path in the readme builder and a shadowed v6 in a test are renamed for what they hold, and the closure returned by isCorrect gets a name. Build scripts are allowed to write to stdout, which is how they report progress. * Check formatting and lint in CI and from a pre-commit hook There was no lint script and no CI step for one, so formatting drift and lint findings only surfaced when someone happened to run the tools by hand. CI now runs both against the whole tree, with eslint pointed at .ts as well as .js and warnings treated as failures so nothing accumulates below the threshold. The check reports rather than corrects. Correcting in CI means granting a workflow write access to the repository, and a token-authored commit does not retrigger workflows, so a pull request would end up with its head unchecked; fork pull requests would still need fixing by hand either way. The same check therefore runs from a pre-commit hook, installed by pointing core.hooksPath at a committed hooks directory, so a violation is caught before it is pushed and `npm run lint:fix` corrects everything mechanical. Extending airbnb-base rather than airbnb drops eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11y from a library with no react in it, taking 377 lines out of the lockfile and with them the warning the react plugin printed on every run because it could not detect a version. The rules that remain are the same ones; airbnb adds only react and accessibility rules on top of that base. * Check that the generated README is current in CI The API reference in the README is generated from the source, including the line numbers its per-method source links point at, so any change under src leaves it stale until `npm run docs` is run again. That happened twice while writing the previous commits and was only noticed by hand. CI now regenerates it and fails if the result differs from what is committed. | 30 天前 | |
Keep the package loadable on node 12, and enforce it (#216) * Emit es2019 so the built output parses on node 12 engines has claimed node >= 12 all along, but nothing enforced it, and a tsconfig target of es2020 let a nullish coalescing operator reach dist as written. Node 12 cannot parse it, so requiring the package threw a SyntaxError at load: not a broken code path but a package that could not be loaded at all on the oldest runtime it claims. Lowering the target to es2019 makes tsc downlevel that operator and refuse any newer syntax at compile time, so the emitted output cannot drift past node 12 again without a build failure. lib stays at es2020 for the bigint types; every es2020 library addition already exists in node 12. The two BigInt literals become BigInt() calls, which is what a target below es2020 requires and what the surrounding code already does. The dev toolchain cannot run on node 12 to catch this: mocha 11, chai 6, tsx and c8 all require node 18 or newer, mocha's own entry point uses node: prefixed requires, and node 12 ships npm 6.14 which cannot read a lockfileVersion 3 lockfile. A matrix entry would fail on the toolchain and report nothing about the library. The new job instead builds dist on a current node and then requires it under node 12, which is what a consumer on an old runtime does and the only place a regression in emitted syntax shows up. The smoke test covers both address families, subnets, BigInt round trips, byte arrays and fromURL, the site of the operator in question. * Format the repository with prettier Seventeen files had drifted from prettier's output, which made a formatting warning on a touched file indistinguishable from one already there and cost time on the previous commit deciding which was which. Everything prettier covers now matches it. Two categories are excluded rather than reformatted. The vendored InterMapper address fixtures stay in the shape they arrived in so they remain comparable against their source. Build output is listed as well, so a local build or coverage run cannot make a check of the whole tree fail on files that are not in the repository. The example block at the top of the README aligns its result comments into a column, which prettier would collapse, so the template marks that one fence prettier-ignore. The marker is an HTML comment and flows through into the generated README, where it does not render. * Clear the eslint findings across src, test and scripts Nothing linted the TypeScript: eslint's default extension list is .js alone, so `eslint .` only ever saw the config file itself and reported clean while seventeen findings sat in the library and its tests. They are all resolved here so the rules can be enforced. no-bitwise is off rather than suppressed. Masks, prefix lengths and the NAT64 and Teredo encodings are defined in terms of shifts and xors, so the rule fires on correct code throughout: nine inline suppressions had accumulated against six live findings, and one suppression had drifted onto the line after the operator it was meant to cover. The suppressions are gone with it. The two ignored catch bindings become optional catch bindings, which es2019 allows and node 12 supports. The NAT64 bit assembly becomes an array joined at the end, so the reserved u octet can be named instead of appearing as a bare string in the middle of a concatenation. A shadowed path in the readme builder and a shadowed v6 in a test are renamed for what they hold, and the closure returned by isCorrect gets a name. Build scripts are allowed to write to stdout, which is how they report progress. * Check formatting and lint in CI and from a pre-commit hook There was no lint script and no CI step for one, so formatting drift and lint findings only surfaced when someone happened to run the tools by hand. CI now runs both against the whole tree, with eslint pointed at .ts as well as .js and warnings treated as failures so nothing accumulates below the threshold. The check reports rather than corrects. Correcting in CI means granting a workflow write access to the repository, and a token-authored commit does not retrigger workflows, so a pull request would end up with its head unchecked; fork pull requests would still need fixing by hand either way. The same check therefore runs from a pre-commit hook, installed by pointing core.hooksPath at a committed hooks directory, so a violation is caught before it is pushed and `npm run lint:fix` corrects everything mechanical. Extending airbnb-base rather than airbnb drops eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11y from a library with no react in it, taking 377 lines out of the lockfile and with them the warning the react plugin printed on every run because it could not detect a version. The rules that remain are the same ones; airbnb adds only react and accessibility rules on top of that base. * Check that the generated README is current in CI The API reference in the README is generated from the source, including the line numbers its per-method source links point at, so any change under src leaves it stale until `npm run docs` is run again. That happened twice while writing the previous commits and was only noticed by hand. CI now regenerates it and fails if the result differs from what is committed. | 30 天前 | |
Keep the package loadable on node 12, and enforce it (#216) * Emit es2019 so the built output parses on node 12 engines has claimed node >= 12 all along, but nothing enforced it, and a tsconfig target of es2020 let a nullish coalescing operator reach dist as written. Node 12 cannot parse it, so requiring the package threw a SyntaxError at load: not a broken code path but a package that could not be loaded at all on the oldest runtime it claims. Lowering the target to es2019 makes tsc downlevel that operator and refuse any newer syntax at compile time, so the emitted output cannot drift past node 12 again without a build failure. lib stays at es2020 for the bigint types; every es2020 library addition already exists in node 12. The two BigInt literals become BigInt() calls, which is what a target below es2020 requires and what the surrounding code already does. The dev toolchain cannot run on node 12 to catch this: mocha 11, chai 6, tsx and c8 all require node 18 or newer, mocha's own entry point uses node: prefixed requires, and node 12 ships npm 6.14 which cannot read a lockfileVersion 3 lockfile. A matrix entry would fail on the toolchain and report nothing about the library. The new job instead builds dist on a current node and then requires it under node 12, which is what a consumer on an old runtime does and the only place a regression in emitted syntax shows up. The smoke test covers both address families, subnets, BigInt round trips, byte arrays and fromURL, the site of the operator in question. * Format the repository with prettier Seventeen files had drifted from prettier's output, which made a formatting warning on a touched file indistinguishable from one already there and cost time on the previous commit deciding which was which. Everything prettier covers now matches it. Two categories are excluded rather than reformatted. The vendored InterMapper address fixtures stay in the shape they arrived in so they remain comparable against their source. Build output is listed as well, so a local build or coverage run cannot make a check of the whole tree fail on files that are not in the repository. The example block at the top of the README aligns its result comments into a column, which prettier would collapse, so the template marks that one fence prettier-ignore. The marker is an HTML comment and flows through into the generated README, where it does not render. * Clear the eslint findings across src, test and scripts Nothing linted the TypeScript: eslint's default extension list is .js alone, so `eslint .` only ever saw the config file itself and reported clean while seventeen findings sat in the library and its tests. They are all resolved here so the rules can be enforced. no-bitwise is off rather than suppressed. Masks, prefix lengths and the NAT64 and Teredo encodings are defined in terms of shifts and xors, so the rule fires on correct code throughout: nine inline suppressions had accumulated against six live findings, and one suppression had drifted onto the line after the operator it was meant to cover. The suppressions are gone with it. The two ignored catch bindings become optional catch bindings, which es2019 allows and node 12 supports. The NAT64 bit assembly becomes an array joined at the end, so the reserved u octet can be named instead of appearing as a bare string in the middle of a concatenation. A shadowed path in the readme builder and a shadowed v6 in a test are renamed for what they hold, and the closure returned by isCorrect gets a name. Build scripts are allowed to write to stdout, which is how they report progress. * Check formatting and lint in CI and from a pre-commit hook There was no lint script and no CI step for one, so formatting drift and lint findings only surfaced when someone happened to run the tools by hand. CI now runs both against the whole tree, with eslint pointed at .ts as well as .js and warnings treated as failures so nothing accumulates below the threshold. The check reports rather than corrects. Correcting in CI means granting a workflow write access to the repository, and a token-authored commit does not retrigger workflows, so a pull request would end up with its head unchecked; fork pull requests would still need fixing by hand either way. The same check therefore runs from a pre-commit hook, installed by pointing core.hooksPath at a committed hooks directory, so a violation is caught before it is pushed and `npm run lint:fix` corrects everything mechanical. Extending airbnb-base rather than airbnb drops eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11y from a library with no react in it, taking 377 lines out of the lockfile and with them the warning the react plugin printed on every run because it could not detect a version. The rules that remain are the same ones; airbnb adds only react and accessibility rules on top of that base. * Check that the generated README is current in CI The API reference in the README is generated from the source, including the line numbers its per-method source links point at, so any change under src leaves it stale until `npm run docs` is run again. That happened twice while writing the previous commits and was only noticed by hand. CI now regenerates it and fails if the result differs from what is committed. | 30 天前 | |
Honor the fromURL graceful-failure contract for non-IPv6 hosts (#218) Address6.fromURL() is documented and typed to return `{ error, address: null, port: null }` when a URL can't be parsed, but that contract was only implemented on the regex-miss path. The URL host character class `[0-9a-f:.]` is a superset of valid IPv6, so any host made only of hex digits, colons and dots matched the regex and was handed straight to `new Address6(host)`, whose AddressError propagated out uncaught. IPv4 literals are the visible case — `http://127.0.0.1/`, `http://169.254.169.254/`, `http://0.0.0.0/` all threw — but so did `[:::]`, `[1:2:3:4:5:6:7:8:9]` and `[::ffff:999.1.1.1]`. A plain hostname like `example.com` avoided the throw only because letters outside a-f break the regex match first. Catch the constructor and return the same error object the regex-miss path returns, so the function never throws for any input. Reported by @zikk090 via GHSA-mxvh-v779-f36j. Declining that as a security advisory: an uncaught synchronous throw from a parser on the caller's own stack is a correctness bug, not a denial of service. | 20 天前 | |
Honor the fromURL graceful-failure contract for non-IPv6 hosts (#218) Address6.fromURL() is documented and typed to return `{ error, address: null, port: null }` when a URL can't be parsed, but that contract was only implemented on the regex-miss path. The URL host character class `[0-9a-f:.]` is a superset of valid IPv6, so any host made only of hex digits, colons and dots matched the regex and was handed straight to `new Address6(host)`, whose AddressError propagated out uncaught. IPv4 literals are the visible case — `http://127.0.0.1/`, `http://169.254.169.254/`, `http://0.0.0.0/` all threw — but so did `[:::]`, `[1:2:3:4:5:6:7:8:9]` and `[::ffff:999.1.1.1]`. A plain hostname like `example.com` avoided the throw only because letters outside a-f break the regex match first. Catch the constructor and return the same error object the regex-miss path returns, so the function never throws for any input. Reported by @zikk090 via GHSA-mxvh-v779-f36j. Declining that as a security advisory: an uncaught synchronous throw from a parser on the caller's own stack is a correctness bug, not a denial of service. | 20 天前 | |
reformat | 5 年前 | |
Keep the package loadable on node 12, and enforce it (#216) * Emit es2019 so the built output parses on node 12 engines has claimed node >= 12 all along, but nothing enforced it, and a tsconfig target of es2020 let a nullish coalescing operator reach dist as written. Node 12 cannot parse it, so requiring the package threw a SyntaxError at load: not a broken code path but a package that could not be loaded at all on the oldest runtime it claims. Lowering the target to es2019 makes tsc downlevel that operator and refuse any newer syntax at compile time, so the emitted output cannot drift past node 12 again without a build failure. lib stays at es2020 for the bigint types; every es2020 library addition already exists in node 12. The two BigInt literals become BigInt() calls, which is what a target below es2020 requires and what the surrounding code already does. The dev toolchain cannot run on node 12 to catch this: mocha 11, chai 6, tsx and c8 all require node 18 or newer, mocha's own entry point uses node: prefixed requires, and node 12 ships npm 6.14 which cannot read a lockfileVersion 3 lockfile. A matrix entry would fail on the toolchain and report nothing about the library. The new job instead builds dist on a current node and then requires it under node 12, which is what a consumer on an old runtime does and the only place a regression in emitted syntax shows up. The smoke test covers both address families, subnets, BigInt round trips, byte arrays and fromURL, the site of the operator in question. * Format the repository with prettier Seventeen files had drifted from prettier's output, which made a formatting warning on a touched file indistinguishable from one already there and cost time on the previous commit deciding which was which. Everything prettier covers now matches it. Two categories are excluded rather than reformatted. The vendored InterMapper address fixtures stay in the shape they arrived in so they remain comparable against their source. Build output is listed as well, so a local build or coverage run cannot make a check of the whole tree fail on files that are not in the repository. The example block at the top of the README aligns its result comments into a column, which prettier would collapse, so the template marks that one fence prettier-ignore. The marker is an HTML comment and flows through into the generated README, where it does not render. * Clear the eslint findings across src, test and scripts Nothing linted the TypeScript: eslint's default extension list is .js alone, so `eslint .` only ever saw the config file itself and reported clean while seventeen findings sat in the library and its tests. They are all resolved here so the rules can be enforced. no-bitwise is off rather than suppressed. Masks, prefix lengths and the NAT64 and Teredo encodings are defined in terms of shifts and xors, so the rule fires on correct code throughout: nine inline suppressions had accumulated against six live findings, and one suppression had drifted onto the line after the operator it was meant to cover. The suppressions are gone with it. The two ignored catch bindings become optional catch bindings, which es2019 allows and node 12 supports. The NAT64 bit assembly becomes an array joined at the end, so the reserved u octet can be named instead of appearing as a bare string in the middle of a concatenation. A shadowed path in the readme builder and a shadowed v6 in a test are renamed for what they hold, and the closure returned by isCorrect gets a name. Build scripts are allowed to write to stdout, which is how they report progress. * Check formatting and lint in CI and from a pre-commit hook There was no lint script and no CI step for one, so formatting drift and lint findings only surfaced when someone happened to run the tools by hand. CI now runs both against the whole tree, with eslint pointed at .ts as well as .js and warnings treated as failures so nothing accumulates below the threshold. The check reports rather than corrects. Correcting in CI means granting a workflow write access to the repository, and a token-authored commit does not retrigger workflows, so a pull request would end up with its head unchecked; fork pull requests would still need fixing by hand either way. The same check therefore runs from a pre-commit hook, installed by pointing core.hooksPath at a committed hooks directory, so a violation is caught before it is pushed and `npm run lint:fix` corrects everything mechanical. Extending airbnb-base rather than airbnb drops eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11y from a library with no react in it, taking 377 lines out of the lockfile and with them the warning the react plugin printed on every run because it could not detect a version. The rules that remain are the same ones; airbnb adds only react and accessibility rules on top of that base. * Check that the generated README is current in CI The API reference in the README is generated from the source, including the line numbers its per-method source links point at, so any change under src leaves it stale until `npm run docs` is run again. That happened twice while writing the previous commits and was only noticed by hand. CI now regenerates it and fails if the result differs from what is committed. | 30 天前 | |
fixes for packaging | 2 年前 | |
Keep the package loadable on node 12, and enforce it (#216) * Emit es2019 so the built output parses on node 12 engines has claimed node >= 12 all along, but nothing enforced it, and a tsconfig target of es2020 let a nullish coalescing operator reach dist as written. Node 12 cannot parse it, so requiring the package threw a SyntaxError at load: not a broken code path but a package that could not be loaded at all on the oldest runtime it claims. Lowering the target to es2019 makes tsc downlevel that operator and refuse any newer syntax at compile time, so the emitted output cannot drift past node 12 again without a build failure. lib stays at es2020 for the bigint types; every es2020 library addition already exists in node 12. The two BigInt literals become BigInt() calls, which is what a target below es2020 requires and what the surrounding code already does. The dev toolchain cannot run on node 12 to catch this: mocha 11, chai 6, tsx and c8 all require node 18 or newer, mocha's own entry point uses node: prefixed requires, and node 12 ships npm 6.14 which cannot read a lockfileVersion 3 lockfile. A matrix entry would fail on the toolchain and report nothing about the library. The new job instead builds dist on a current node and then requires it under node 12, which is what a consumer on an old runtime does and the only place a regression in emitted syntax shows up. The smoke test covers both address families, subnets, BigInt round trips, byte arrays and fromURL, the site of the operator in question. * Format the repository with prettier Seventeen files had drifted from prettier's output, which made a formatting warning on a touched file indistinguishable from one already there and cost time on the previous commit deciding which was which. Everything prettier covers now matches it. Two categories are excluded rather than reformatted. The vendored InterMapper address fixtures stay in the shape they arrived in so they remain comparable against their source. Build output is listed as well, so a local build or coverage run cannot make a check of the whole tree fail on files that are not in the repository. The example block at the top of the README aligns its result comments into a column, which prettier would collapse, so the template marks that one fence prettier-ignore. The marker is an HTML comment and flows through into the generated README, where it does not render. * Clear the eslint findings across src, test and scripts Nothing linted the TypeScript: eslint's default extension list is .js alone, so `eslint .` only ever saw the config file itself and reported clean while seventeen findings sat in the library and its tests. They are all resolved here so the rules can be enforced. no-bitwise is off rather than suppressed. Masks, prefix lengths and the NAT64 and Teredo encodings are defined in terms of shifts and xors, so the rule fires on correct code throughout: nine inline suppressions had accumulated against six live findings, and one suppression had drifted onto the line after the operator it was meant to cover. The suppressions are gone with it. The two ignored catch bindings become optional catch bindings, which es2019 allows and node 12 supports. The NAT64 bit assembly becomes an array joined at the end, so the reserved u octet can be named instead of appearing as a bare string in the middle of a concatenation. A shadowed path in the readme builder and a shadowed v6 in a test are renamed for what they hold, and the closure returned by isCorrect gets a name. Build scripts are allowed to write to stdout, which is how they report progress. * Check formatting and lint in CI and from a pre-commit hook There was no lint script and no CI step for one, so formatting drift and lint findings only surfaced when someone happened to run the tools by hand. CI now runs both against the whole tree, with eslint pointed at .ts as well as .js and warnings treated as failures so nothing accumulates below the threshold. The check reports rather than corrects. Correcting in CI means granting a workflow write access to the repository, and a token-authored commit does not retrigger workflows, so a pull request would end up with its head unchecked; fork pull requests would still need fixing by hand either way. The same check therefore runs from a pre-commit hook, installed by pointing core.hooksPath at a committed hooks directory, so a violation is caught before it is pushed and `npm run lint:fix` corrects everything mechanical. Extending airbnb-base rather than airbnb drops eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11y from a library with no react in it, taking 377 lines out of the lockfile and with them the warning the react plugin printed on every run because it could not detect a version. The rules that remain are the same ones; airbnb adds only react and accessibility rules on top of that base. * Check that the generated README is current in CI The API reference in the README is generated from the source, including the line numbers its per-method source links point at, so any change under src leaves it stale until `npm run docs` is run again. That happened twice while writing the previous commits and was only noticed by hand. CI now regenerates it and fails if the result differs from what is committed. | 30 天前 | |
Keep the package loadable on node 12, and enforce it (#216) * Emit es2019 so the built output parses on node 12 engines has claimed node >= 12 all along, but nothing enforced it, and a tsconfig target of es2020 let a nullish coalescing operator reach dist as written. Node 12 cannot parse it, so requiring the package threw a SyntaxError at load: not a broken code path but a package that could not be loaded at all on the oldest runtime it claims. Lowering the target to es2019 makes tsc downlevel that operator and refuse any newer syntax at compile time, so the emitted output cannot drift past node 12 again without a build failure. lib stays at es2020 for the bigint types; every es2020 library addition already exists in node 12. The two BigInt literals become BigInt() calls, which is what a target below es2020 requires and what the surrounding code already does. The dev toolchain cannot run on node 12 to catch this: mocha 11, chai 6, tsx and c8 all require node 18 or newer, mocha's own entry point uses node: prefixed requires, and node 12 ships npm 6.14 which cannot read a lockfileVersion 3 lockfile. A matrix entry would fail on the toolchain and report nothing about the library. The new job instead builds dist on a current node and then requires it under node 12, which is what a consumer on an old runtime does and the only place a regression in emitted syntax shows up. The smoke test covers both address families, subnets, BigInt round trips, byte arrays and fromURL, the site of the operator in question. * Format the repository with prettier Seventeen files had drifted from prettier's output, which made a formatting warning on a touched file indistinguishable from one already there and cost time on the previous commit deciding which was which. Everything prettier covers now matches it. Two categories are excluded rather than reformatted. The vendored InterMapper address fixtures stay in the shape they arrived in so they remain comparable against their source. Build output is listed as well, so a local build or coverage run cannot make a check of the whole tree fail on files that are not in the repository. The example block at the top of the README aligns its result comments into a column, which prettier would collapse, so the template marks that one fence prettier-ignore. The marker is an HTML comment and flows through into the generated README, where it does not render. * Clear the eslint findings across src, test and scripts Nothing linted the TypeScript: eslint's default extension list is .js alone, so `eslint .` only ever saw the config file itself and reported clean while seventeen findings sat in the library and its tests. They are all resolved here so the rules can be enforced. no-bitwise is off rather than suppressed. Masks, prefix lengths and the NAT64 and Teredo encodings are defined in terms of shifts and xors, so the rule fires on correct code throughout: nine inline suppressions had accumulated against six live findings, and one suppression had drifted onto the line after the operator it was meant to cover. The suppressions are gone with it. The two ignored catch bindings become optional catch bindings, which es2019 allows and node 12 supports. The NAT64 bit assembly becomes an array joined at the end, so the reserved u octet can be named instead of appearing as a bare string in the middle of a concatenation. A shadowed path in the readme builder and a shadowed v6 in a test are renamed for what they hold, and the closure returned by isCorrect gets a name. Build scripts are allowed to write to stdout, which is how they report progress. * Check formatting and lint in CI and from a pre-commit hook There was no lint script and no CI step for one, so formatting drift and lint findings only surfaced when someone happened to run the tools by hand. CI now runs both against the whole tree, with eslint pointed at .ts as well as .js and warnings treated as failures so nothing accumulates below the threshold. The check reports rather than corrects. Correcting in CI means granting a workflow write access to the repository, and a token-authored commit does not retrigger workflows, so a pull request would end up with its head unchecked; fork pull requests would still need fixing by hand either way. The same check therefore runs from a pre-commit hook, installed by pointing core.hooksPath at a committed hooks directory, so a violation is caught before it is pushed and `npm run lint:fix` corrects everything mechanical. Extending airbnb-base rather than airbnb drops eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11y from a library with no react in it, taking 377 lines out of the lockfile and with them the warning the react plugin printed on every run because it could not detect a version. The rules that remain are the same ones; airbnb adds only react and accessibility rules on top of that base. * Check that the generated README is current in CI The API reference in the README is generated from the source, including the line numbers its per-method source links point at, so any change under src leaves it stale until `npm run docs` is run again. That happened twice while writing the previous commits and was only noticed by hand. CI now regenerates it and fails if the result differs from what is committed. | 30 天前 | |
more formatting, remove unused packages | 2 年前 | |
Keep the package loadable on node 12, and enforce it (#216) * Emit es2019 so the built output parses on node 12 engines has claimed node >= 12 all along, but nothing enforced it, and a tsconfig target of es2020 let a nullish coalescing operator reach dist as written. Node 12 cannot parse it, so requiring the package threw a SyntaxError at load: not a broken code path but a package that could not be loaded at all on the oldest runtime it claims. Lowering the target to es2019 makes tsc downlevel that operator and refuse any newer syntax at compile time, so the emitted output cannot drift past node 12 again without a build failure. lib stays at es2020 for the bigint types; every es2020 library addition already exists in node 12. The two BigInt literals become BigInt() calls, which is what a target below es2020 requires and what the surrounding code already does. The dev toolchain cannot run on node 12 to catch this: mocha 11, chai 6, tsx and c8 all require node 18 or newer, mocha's own entry point uses node: prefixed requires, and node 12 ships npm 6.14 which cannot read a lockfileVersion 3 lockfile. A matrix entry would fail on the toolchain and report nothing about the library. The new job instead builds dist on a current node and then requires it under node 12, which is what a consumer on an old runtime does and the only place a regression in emitted syntax shows up. The smoke test covers both address families, subnets, BigInt round trips, byte arrays and fromURL, the site of the operator in question. * Format the repository with prettier Seventeen files had drifted from prettier's output, which made a formatting warning on a touched file indistinguishable from one already there and cost time on the previous commit deciding which was which. Everything prettier covers now matches it. Two categories are excluded rather than reformatted. The vendored InterMapper address fixtures stay in the shape they arrived in so they remain comparable against their source. Build output is listed as well, so a local build or coverage run cannot make a check of the whole tree fail on files that are not in the repository. The example block at the top of the README aligns its result comments into a column, which prettier would collapse, so the template marks that one fence prettier-ignore. The marker is an HTML comment and flows through into the generated README, where it does not render. * Clear the eslint findings across src, test and scripts Nothing linted the TypeScript: eslint's default extension list is .js alone, so `eslint .` only ever saw the config file itself and reported clean while seventeen findings sat in the library and its tests. They are all resolved here so the rules can be enforced. no-bitwise is off rather than suppressed. Masks, prefix lengths and the NAT64 and Teredo encodings are defined in terms of shifts and xors, so the rule fires on correct code throughout: nine inline suppressions had accumulated against six live findings, and one suppression had drifted onto the line after the operator it was meant to cover. The suppressions are gone with it. The two ignored catch bindings become optional catch bindings, which es2019 allows and node 12 supports. The NAT64 bit assembly becomes an array joined at the end, so the reserved u octet can be named instead of appearing as a bare string in the middle of a concatenation. A shadowed path in the readme builder and a shadowed v6 in a test are renamed for what they hold, and the closure returned by isCorrect gets a name. Build scripts are allowed to write to stdout, which is how they report progress. * Check formatting and lint in CI and from a pre-commit hook There was no lint script and no CI step for one, so formatting drift and lint findings only surfaced when someone happened to run the tools by hand. CI now runs both against the whole tree, with eslint pointed at .ts as well as .js and warnings treated as failures so nothing accumulates below the threshold. The check reports rather than corrects. Correcting in CI means granting a workflow write access to the repository, and a token-authored commit does not retrigger workflows, so a pull request would end up with its head unchecked; fork pull requests would still need fixing by hand either way. The same check therefore runs from a pre-commit hook, installed by pointing core.hooksPath at a committed hooks directory, so a violation is caught before it is pushed and `npm run lint:fix` corrects everything mechanical. Extending airbnb-base rather than airbnb drops eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11y from a library with no react in it, taking 377 lines out of the lockfile and with them the warning the react plugin printed on every run because it could not detect a version. The rules that remain are the same ones; airbnb adds only react and accessibility rules on top of that base. * Check that the generated README is current in CI The API reference in the README is generated from the source, including the line numbers its per-method source links point at, so any change under src leaves it stale until `npm run docs` is run again. That happened twice while writing the previous commits and was only noticed by hand. CI now regenerates it and fails if the result differs from what is committed. | 30 天前 | |
Adding the MIT license | 15 年前 | |
Honor the fromURL graceful-failure contract for non-IPv6 hosts (#218) Address6.fromURL() is documented and typed to return `{ error, address: null, port: null }` when a URL can't be parsed, but that contract was only implemented on the regex-miss path. The URL host character class `[0-9a-f:.]` is a superset of valid IPv6, so any host made only of hex digits, colons and dots matched the regex and was handed straight to `new Address6(host)`, whose AddressError propagated out uncaught. IPv4 literals are the visible case — `http://127.0.0.1/`, `http://169.254.169.254/`, `http://0.0.0.0/` all threw — but so did `[:::]`, `[1:2:3:4:5:6:7:8:9]` and `[::ffff:999.1.1.1]`. A plain hostname like `example.com` avoided the throw only because letters outside a-f break the regex match first. Catch the constructor and return the same error object the regex-miss path returns, so the function never throws for any input. Reported by @zikk090 via GHSA-mxvh-v779-f36j. Declining that as a security advisory: an uncaught synchronous throw from a parser on the caller's own stack is a correctness bug, not a denial of service. | 20 天前 | |
Add a security policy and a README section on security posture There was no SECURITY.md, so the repository's security tab showed no policy even though private vulnerability reporting is enabled and is how reports already arrive. The policy names the reporting channel, what makes a report useful, which versions get fixes, and what falls in and out of scope. Both files state plainly that the address-property checks are one layer of an SSRF guard rather than a guard, since every advisory published against this library so far has come from that assumption. They also spell out that isValid() returning false means the string is not a valid literal of that family, not that it cannot reach an internal host: 2130706433, 0x7f000001 and 127.1 are all rejected here and all resolve to loopback. The README section records how releases are built and verified, including that provenance attestations start at 10.2.1 rather than covering every version. | 1 个月前 | |
circleci tweaks | 2 年前 | |
10.4.0 | 30 天前 | |
10.4.0 | 30 天前 | |
Keep the package loadable on node 12, and enforce it (#216) * Emit es2019 so the built output parses on node 12 engines has claimed node >= 12 all along, but nothing enforced it, and a tsconfig target of es2020 let a nullish coalescing operator reach dist as written. Node 12 cannot parse it, so requiring the package threw a SyntaxError at load: not a broken code path but a package that could not be loaded at all on the oldest runtime it claims. Lowering the target to es2019 makes tsc downlevel that operator and refuse any newer syntax at compile time, so the emitted output cannot drift past node 12 again without a build failure. lib stays at es2020 for the bigint types; every es2020 library addition already exists in node 12. The two BigInt literals become BigInt() calls, which is what a target below es2020 requires and what the surrounding code already does. The dev toolchain cannot run on node 12 to catch this: mocha 11, chai 6, tsx and c8 all require node 18 or newer, mocha's own entry point uses node: prefixed requires, and node 12 ships npm 6.14 which cannot read a lockfileVersion 3 lockfile. A matrix entry would fail on the toolchain and report nothing about the library. The new job instead builds dist on a current node and then requires it under node 12, which is what a consumer on an old runtime does and the only place a regression in emitted syntax shows up. The smoke test covers both address families, subnets, BigInt round trips, byte arrays and fromURL, the site of the operator in question. * Format the repository with prettier Seventeen files had drifted from prettier's output, which made a formatting warning on a touched file indistinguishable from one already there and cost time on the previous commit deciding which was which. Everything prettier covers now matches it. Two categories are excluded rather than reformatted. The vendored InterMapper address fixtures stay in the shape they arrived in so they remain comparable against their source. Build output is listed as well, so a local build or coverage run cannot make a check of the whole tree fail on files that are not in the repository. The example block at the top of the README aligns its result comments into a column, which prettier would collapse, so the template marks that one fence prettier-ignore. The marker is an HTML comment and flows through into the generated README, where it does not render. * Clear the eslint findings across src, test and scripts Nothing linted the TypeScript: eslint's default extension list is .js alone, so `eslint .` only ever saw the config file itself and reported clean while seventeen findings sat in the library and its tests. They are all resolved here so the rules can be enforced. no-bitwise is off rather than suppressed. Masks, prefix lengths and the NAT64 and Teredo encodings are defined in terms of shifts and xors, so the rule fires on correct code throughout: nine inline suppressions had accumulated against six live findings, and one suppression had drifted onto the line after the operator it was meant to cover. The suppressions are gone with it. The two ignored catch bindings become optional catch bindings, which es2019 allows and node 12 supports. The NAT64 bit assembly becomes an array joined at the end, so the reserved u octet can be named instead of appearing as a bare string in the middle of a concatenation. A shadowed path in the readme builder and a shadowed v6 in a test are renamed for what they hold, and the closure returned by isCorrect gets a name. Build scripts are allowed to write to stdout, which is how they report progress. * Check formatting and lint in CI and from a pre-commit hook There was no lint script and no CI step for one, so formatting drift and lint findings only surfaced when someone happened to run the tools by hand. CI now runs both against the whole tree, with eslint pointed at .ts as well as .js and warnings treated as failures so nothing accumulates below the threshold. The check reports rather than corrects. Correcting in CI means granting a workflow write access to the repository, and a token-authored commit does not retrigger workflows, so a pull request would end up with its head unchecked; fork pull requests would still need fixing by hand either way. The same check therefore runs from a pre-commit hook, installed by pointing core.hooksPath at a committed hooks directory, so a violation is caught before it is pushed and `npm run lint:fix` corrects everything mechanical. Extending airbnb-base rather than airbnb drops eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11y from a library with no react in it, taking 377 lines out of the lockfile and with them the warning the react plugin printed on every run because it could not detect a version. The rules that remain are the same ones; airbnb adds only react and accessibility rules on top of that base. * Check that the generated README is current in CI The API reference in the README is generated from the source, including the line numbers its per-method source links point at, so any change under src leaves it stale until `npm run docs` is run again. That happened twice while writing the previous commits and was only noticed by hand. CI now regenerates it and fails if the result differs from what is committed. | 30 天前 |
项目 README 为空
项目介绍
💻 a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript
MIT TypeScript503提交数addressarpabigintbrowsercidripipv4ipv6javascriptnetmaskparsesubnettypescriptvalidatevalidation
定制我的领域