Adds existing npm lib multicodec + tests

[carsonfarmer]

Signed-off-by: Carson Farmer carson.farmer@gmail.com

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change. (Run with npm test.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If adding a new definition:

• The package does not already provide its own types, or cannot have its .d.ts files generated via --declaration
• If this is for an NPM package, match the name. If not, do not conflict with the name of an NPM package.
• Create it with dts-gen --dt, not by basing it on an existing project.
• Represents shape of module/library correctly
• tslint.json should be present and it shouldn't have any additional or disabling of rules. Just content as { "extends": "dtslint/dt.json" }. If for reason the some rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.
• tsconfig.json should have noImplicitAny, noImplicitThis, strictNullChecks, and strictFunctionTypes set to true.

[typescript-bot]

@carsonfarmer Thank you for submitting this PR!

Because this is a new definition, a DefinitelyTyped maintainer will be reviewing this PR in the next few days once the Travis CI build passes.

In the meantime, if the build fails or a merge conflict occurs, I'll let you know. Have a nice day!

[carsonfarmer]

Could this 'feature' be better represented using a namespace?

[typescript-bot]

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

These typings are for a package that doesn’t yet exist on master, so I don’t have anything to compare against yet! In the future, I’ll be able to compare PRs to multicodec with its source on master.

Comparison details 📊

Batch compilation
Type count	10170
Assignability cache size	3022
Language service measurements
Samples taken	120
Identifiers in tests	120
getCompletionsAtPosition
Mean duration (ms)	369.3
Mean CV	11.9%
Worst duration (ms)	483.1
Worst identifier	print
getQuickInfoAtPosition
Mean duration (ms)	362.1
Mean CV	11.4%
Worst duration (ms)	444.5
Worst identifier	print
System information
Node version	v12.13.1
CPU count	2
CPU speed	2.294 GHz
CPU model	Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
CPU Architecture	x64
Memory	6.8 GiB
Platform	linux
Release	4.15.0-1064-azure

[armanio123]

I think multicodec also provides a global value. See https://www.typescriptlang.org/docs/handbook/declaration-files/library-structures.html#global-libraries for details on how to represent this.

[typescript-bot]

@carsonfarmer One or more reviewers has requested changes. Please address their comments. I'll be back once they sign off or you've pushed new commits or comments. Thank you!

[carsonfarmer]

Typo fixed, good catch!

I think multicodec also provides a global value. See https://www.typescriptlang.org/docs/handbook/declaration-files/library-structures.html#global-libraries for details on how to represent this.

Maybe I'm missing something, but I don't see any evidence of this? The aegir build script produces a webpack umd, but doesn't look like there are any globals available..? Could you point me to where I might find this?

[typescript-bot]

🔔 @armanio123 - Thanks for your review of this PR! Can you please look at the new code and update your review status if appropriate?

[armanio123]

Maybe I'm missing something, but I don't see any evidence of this? The aegir build script produces a webpack umd, but doesn't look like there are any globals available..? Could you point me to where I might find this?

Here's documentation of multicodec used on the browser: https://multiformats.github.io/js-multicodec/

If you check file https://unpkg.com/multicodec@1.0.0/dist/index.js, line 9:

root["Multicodec"] = factory();

That's where the global variable is being assigned.

[carsonfarmer]

Ah I see, thanks @armanio123, I didn't read that initial link you posted properly. My apologies, yes you are right, and I think the added export as namespace Multicodec should cover it. Though it wasn't clear to me how best to 'test' this?

[armanio123]

Though it wasn't clear to me how best to 'test' this?

Since you're declaring a global variable by exporting the namespace, you should be able to access it's properties en methods just by using Multicodec on the test file (no import required).

[carsonfarmer]

Cool, so that's great. But is it only available globally in a browser context? If I look at the "main" entry in the package.json I see "src/index.js", which does not have anything exported globally. Is this still 'ok' from a ambient types perspective? Apologies for my ignorance here, this is apparently the first package that has a global export that I've written types for 😬.

So I guess my final question here is, is it misleading to have globally exported types in say a NodeJS context? I see that if I do include the import, this masks the global value, which makes sense. However, in NodeJS, if I don't import the package, I won't actually have it in my global namespace...

[armanio123]

So I guess my final question here is, is it misleading to have globally exported types in say a NodeJS context? I see that if I do include the import, this masks the global value, which makes sense. However, in NodeJS, if I don't import the package, I won't actually have it in my global namespace...

I can see how this is confusing, but that's how umd modules work. It would be up to the developer to understand the library and decide the best implementation. As you correctly stated, in the case of a NodeJs environment, you require specify the import. For the case of the browser you must reference the global library by using a script block (I think the author documented this to be on the dist folder) and make the global variable available.

Btw for test purposes both scenarios should be ok. You can either decide to import or use the global scope. I'll approve and merge the PR.

[typescript-bot]

I just published @types/multicodec@1.0.0 to npm.

[carsonfarmer]

Thanks so much for a) explaining this, super helpful, and b) approving and merging! Cheers @armanio123!