search

square / find-yarn-workspace-root

Algorithm for finding the root of a yarn workspace, extracted from yarnpkg.com
Apache License 2.0
49 stars 8 forks source link

chore: add typescript declaration #13

Closed gfmio closed 6 years ago

gfmio commented 6 years ago

Following my request in issue #12, this PR adds a TypeScript declaration file to this package. It can now be used in TypeScript with the following import (similar to many other older JS libraries like express).

import * as findWorkspaceRoot from "find-yarn-workspace-root";
gfmio commented 6 years ago

Re the import issue:

No, you can do both and both ways are equivalent. The import * as X from "x" construct is the way a lot of libraries that just export a function are consumed, for example express.

The reason why the export is callable like this is because the function and namespace have the same name. Here's a small snippet to illustrate:

import * as express from "express";
import express2 from "express";
import express3 = require("express");

import * as findWorkspaceRoot from "../../../open-source/find-yarn-workspace-root";
import findWorkspaceRoot2 from "../../../open-source/find-yarn-workspace-root";
import findWorkspaceRoot3 = require("../../../open-source/find-yarn-workspace-root");

console.log(typeof express);
console.log(typeof express2);
console.log(typeof express3);

console.log(typeof findWorkspaceRoot);
console.log(typeof findWorkspaceRoot2);
console.log(typeof findWorkspaceRoot3);

I'm importing both express and my local copy of this package in three different ways. The second one would be a default import and doesn't work (for either express or this package). The first and third are equivalent. The output is:

function
undefined
function
function
undefined
function

Also, I should add this example only compiles if you have the allowSyntheticDefaultImports set to true, because the compiler will otherwise flag the second attempted import as invalid from the get-go. But no matter if you have allowSyntheticDefaultImports set, the first and third way both still work and are equivalent.

eventualbuddha commented 6 years ago

While in some implementations of ES modules the namespace import object may in fact be a function, that is incorrect according to the spec. See https://github.com/Microsoft/TypeScript/issues/16093.

gfmio commented 6 years ago

Thanks for merging it in. Interesting that the above import behaviour is not according to spec, especially since it is so commonly used (not that that means anything). Anyway, thanks for the pointer.

Will you release a new version with this? I thought a CI tool would handle that, but I just checked, and no new version has been released so far. Is anything holding this back?

eventualbuddha commented 6 years ago

Whoops, sorry about that. Most of my own projects use semantic-release which automatically bumps the version and does releases. This repository does not, but uses standard-version which is sort of a middle-ground of automatic releases but not automatic versioning. This should be included in v1.2.1 now.

gfmio commented 6 years ago

No worries & thanks for pushing the new version!