Unified "install"

[unional]

Placeholder for discussed ideas.

[unional]

When both package.json and registry version exists, which one should the user pick?

It is good that we provide the flexibility and allow user to choose freely, but that ability to choose could also be a burden to the user as they need to know which one is more accurate. Any thoughts on that?

Would it be possible to unify it and have a flag in the typings.json of the typed module (e.g. typed-domready to indicate which one should be used?

In that case, by default the module included typings would be used, but that default can be overridden if the non-github / private modules author can not maintain the included typing.

This could also simplify the typings install syntax. 😄

[unional]

# from
typings install domready --name dr
# to
typings install dr=domready

# in jspm
jspm install dr=domready
jspm install dr=npm:domready
jspm install dr=github:ded/domready

If ambientize to domready, then simply

typings install domready
# in jspm
jpsm install domready

Also, -S is the default. i.e.:

jspm install domready

will update jspm.config.js and package.json.

and

typings install domready

will update typings.json

# from
typings install core-js --ambient
# to
typings install dt:core-js

As we are getting the ambient version from DefinitelyTyped anyway.

Ambientized external module declaration is (or suppose to) share the same shape as its ambient version, so:

typings install npm:core-js --ambient
# is equivalent to
typings install npm:core-js

From Blake:
For now.

In general, I really like the idea but it's not compatible (npm:core-js). This scheme is already used to resolve (E.g. from node_modules, from GitHub, from file, etc), so this would be a major breaking change that I don't currently see as needed. I would like a better way to make these simpler, but breaking the current scheme isn't one. For now you could typings install core-js -s dt.

The other issue is that these are "polyfill" typings. These aren't the same as installing the source code, there's an extra layer in the middle usually. E.g. NPM registry -> Typings registry (marked as npm) -> GitHub.

As for the immediate save option, what about -D? I do like the idea of automatically writing as you install, just need a complete suggestion of what'll work differently. This is also another thing that would go to the next major release, not the current release train.

Finally, I think the last suggestion is around automatically using ambient vs non-ambient? I'm sort of off for that because there's already a lot of confusion around the difference between ambient and normal dependencies, etc. and when the get resolved/installed/etc. I like the explicitness. One suggestion for these that I loved was having a default normal and ambient source when installing (which you actually suggested: #126 (comment)).

[unional]

Haha, I knew i missed something: ambient and unify + override.

Let me try to explain a little more in what I mean unify approach:

1. typings install npm:domready
2. Open node_modules/domready/package.json, if not found, look it up from npm registry (like what jspm do).
3. Read version and typings from package.json
4. Go to https://github.com/typings/registry/npm/domready.json
5. See if there is a compatible community typed file, e.g. https://github.com/unional/typed-domready Look for a compatible version of community typed file, e.g. https://github.com/unional/typed-domready#commitSHA123
6. Open https://github.com/unional/typed-domready/typings.json https://github.com/unional/typed-domready/blob/commitSHA123/typings.json
7. Check where if the module included typings from 3 should be preferred (if it exists)
8. Read either locally or on (6) depending on the result.
9. Ambientize it

If the user wants to override that, user can do typings install npm:domready --community or typings install npm:domready --local

UPDATE:

2. ...look it up from npm registry

Query npm directly, jspm endpoint does similar things. Since we only get the package.json (similar to npm info), it shouldn't be a problem.

[unional]

Will sort these idea out when I have time to

[blakeembrey]

Not sure if you resolved this, but I think I'm going to release this change with 0.7. The API/syntax will be <name>=<source>!<name> or <name>=<scheme>:<path>. The new "bang scheme" looks up the registry first and will usually be denoted by a version. For example, npm!debug@1.0.0-<timestamp> (from recent release with https://api.typings.org/versions/npm/debug), but it'll also allow a range behaviour like today.

[unional]

Sounds good!

[unional]

In light of:
typings/registry#142 (comment)

Maybe we can simplify the syntax for most packages to typings install <packageName> by either:
a. Specify default distribution channel in typings.json or .typingsrc
b. Have a default entry in registry (without npm- prefix), similar to jspm endpoint
c. Implicit default by identifying the existence of package.json, bower.json, node_modules, jspm_packages, etc

[blakeembrey]

Yep, that's the idea. I believe it's a discussion we had a long while back and has evolved little by little until today.

a) 👍
b) Can you elaborate here? Not sure I'm following.
c) Yes, possible. I actually think typings sync might be even better - it can automatically synchronise typings.json with package.json, for instance.

[unional]

About (b):
jspm registry/endpoint acts like an alias registry. It maps sources from various places (github or npm) to a simple name.

By default, jspm supports installing directly from npm and github:

jspm install npm:domready
jspm install github:unional/unional-umd

Adding entries in the registry.json allows user to:

jspm install domready
jspm install unional-umd

[blakeembrey]

Right, but that's a mapping for a single registry. We're a mapping for multiple registries. I can't quite see how that'd work for everything, so I think (a) makes more sense here. At least on Bower/JSPM/etc. project you could check in a .typingsrc file that changes the default to whatever you're working with.

Edit: As always, you're open to try to convince me otherwise 😉

[unional]

As always, you're open to try to convince me otherwise

Yes Sir! 😜

[unional]

This is a easy one:

+ npm
+ -- domready.json
+ registry.json

// npm/domready.json
{
  // the usual thing
  "versions": { ... }
}

// registry.json
{
  "domready": "./npm/domready.json"
}

🍺

[unional]

Yes, I understand the concern for bower/jspm does not go away with this approach. Need a bit more brainstorming. 😄

[unional]

But on the other hand, if .typingsrc set default to bower and registry only has npm/domready.json, what to do? I think (a) and (b) can be combined to solve this issue.

[blakeembrey]

Right, but what does registry.json really mean here. That this is the most likely you'd want to install according to us? It also makes things a lot trickier for resolution and requires API changes. I like defaults on the client-side more, just because it's configurable.

[blakeembrey]

On your concern, it shouldn't be installed. In general, I don't want to just fallback to different sources - it could be an entirely different module. If it is the same module, we should have the entry under bower/ too.

[unional]

Sounds good. And that would address the version discrepancy issue too.

[blakeembrey]

Yes 👍 Right now, the implicit stuff seemed cool - but as I've discovered it's caused too many issues and implicit behaviours. I think this will be a good improvement, and killing the prompts will be amazing!

[unional]

And /usr/local/bin/.typingsrc can dictate the user default channel.

[unional]

I start feeling "distribution channel" is too much typings. 😛

[unional]

That this is the most likely you'd want to install according to us

While this concern is valid and I also agree to it. 99% of the time it will work correctly.
But like you said, client side config would be better.

Just adding this comment to record this opinion. 😄

[unional]

Referencing:
typings/typings#436

And I think this can be closed. 😄