removing the need of typings/registry/global

[unional]

I'm doing this locally and it seems to work well:

// get a package with module typings
npm i my-module-with-typing
typing i npm~some-module

// custom-typings/my-module-with-typing.d.ts
export * from 'my-module-with-typings'
export as namespace MyModuleWithTypings

// custom-typings/some-module
export * from 'some-module'
export as namespace SomeModule

Maybe typings can create those custom typings files directly?
In this case, we can reduce the registry by half.

Of course, one issue is how to determine the module's namespace.
How will DT do it for @types?

Lately, I'm working on globalify and released my own @unional/globalify which I can define my own global namespace variable.
It can help but still need to deal with libraries that already release global umd build with special namespace variable.

[unional]

When redirect is landed, I think we can put the namespace variable in typings.json. 🌷

[blakeembrey]

I'm not sure we can make the change though, because it seems like it's creating external module entities and would only work with TypeScript 2.0+. I think I'd prefer to just have microsoft/types-publisher#4 land already and avoid thinking about some of these issues, unless there's a really simple and well defined change that won't impact too many old clients.

[unional]

Sure.

When microsoft/types-publisher#4 lands, the types/* repos can remove the global typings?

[blakeembrey]

I think it should still be there. At least, I don't see any reason to remove it? It isn't just used for workarounds of UMD.

[unional]

um...What's the use of it? npm i @types/* will get the module typings only, right?
And using npm i @typs/*, the module typings can start doing exports as namespace ... for umd build.

I'm just thinking of what should be done and recommended practice on writing the typings in the repo.

(and maybe updating the generator to reflect it).

[blakeembrey]

Sure, makes sense. I'd take a look at what is in there today: https://github.com/typings/registry/tree/master/global. Some of these are actually global only (e.g. no module system) or can't be supported by NPM @types (meteor), so there's still a place to put those. Not all globals are UMD (e.g. browser SDKs like Stripe).

[unional]

Wonder how @types is handling those...

[blakeembrey]

I think the general idea with @types is "NPM only and globals can be added to DefinitelyTyped". Not sure if that'll ever change when a real conflict occurs in global vs module versions. The only one I can think of off the top of my head is actually stripe (e.g. https://www.npmjs.com/package/stripe) but I think the workaround there will be "use stripe and stripe.js to make them different" until, god-forbid, someone wants to type something like https://www.npmjs.com/package/stripe.js. So conflicts can 100% occur, it's just they haven't yet because enough modules haven't been typed.

[unional]

I just think about the old problem we discuss when deciding on the naming convention of repo.

What we were trying to solve was to uniquely identify the code.
Now as I think of it, it is not really about the naming, but a id json:

{
  source: '..github url'
  packages: {
    npm: 'name',
    bower: 'name',
    cdn/global: '...'
    ...
  }
}

Maybe it would be useful for redirect?

[blakeembrey]

I definitely prefer that structure, but it comes back to how we name our repos and the file that contains that itself then. I suppose we could just make the JSON and repo names semantically meaningless (keep things as close as possible, of course, but unused for names). Then we use those flags to put it into the right places. At this point though, I'm unlikely to change it as the user base should be migrating away and my time is probably better spent on new projects now.

[unional]

That's a proposal we can make to the TS team for the submodules repos.

Add that as part of typings.json