Skip to content

Support shorthand ambient module declarations and wildcard chars in module names #6615

Closed
Closed
Support shorthand ambient module declarations and wildcard chars in module names#6615
Labels
CommittedThe team has roadmapped this issueFixedA PR has been merged for this issueSuggestionAn idea for TypeScript
Milestone
TypeScript 2.0

Description

@mhegazy
Mohamed Hegazy (mhegazy)
opened on Jan 25, 2016

follow up on #6614

Related issues: #247 (comment), #5787, #2709, #6371 (comment)

Problems:

  • Can not easily specify a loader extension for json or css (e.g. `json!a.json); currently every resources needs to have its own declaration
  • Problem with migrating to .ts, with modules that do not have typings, and users just want to get by

Proposal:

  • Allow for short hand module declarations:

    declare module "foo";

    to be equivalent to:

    declare module "foo" {
    var _temp: any;
    export = _temp;
}

  • Allow module names to have a wildcard character and match that in lookup

    declare module "json!*" {
    let json: any;
    export default json;
}

import d from "json!a/b/bar.json";
// lookup:
//    json!a/b/bar.json
//    json!*

  • Additional the module "*" would allow for matching all unknown modules in the system, which can be used as a way to suppress all missing module errors

    declare module "*";

import d from "some\unknown\module"; // no error, d is any

  • Report no-implicit-any errors for modules declared using the shorthand notion
    Open issue: is this reported on declaration or use sites

Activity

  1. Mohamed Hegazy (mhegazy)
    added
    SuggestionAn idea for TypeScript
    CommittedThe team has roadmapped this issue
    on Jan 25, 2016
  2. Mohamed Hegazy (mhegazy)
    added this to the TypeScript 2.0 milestone on Jan 25, 2016
  3. Mohamed Hegazy (mhegazy)
    self-assigned this
    on Jan 25, 2016

  4. mkosieradzki commented on Jan 25, 2016

    @mkosieradzki
    Marcin Kosieradzki (mkosieradzki)
    on Jan 25, 2016

    Epic solution for #2709 !

  5. dfaivre commented on Jan 25, 2016

    @dfaivre
    David Faivre (dfaivre)
    on Jan 25, 2016

    Nice to see this is being worked on -- looks like an interesting solution that neatly captures all the outstanding requests.

    Personally, I'd also like to see a compiler flag for the declare module "*"; use case -- it seems a little more natural, something like noExplicitAny, except for modules.

    Thanks again for all the great work!

  6. nillis commented on Jan 25, 2016

    @nillis
    Niels Timmermans (nillis)
    on Jan 25, 2016

    +1
    Great solution! Looking forward to be able to delete all modules I created manually to keep the compiler happy

  7. ivogabe commented on Jan 25, 2016

    @ivogabe
    Ivo Gabe de Wolff (ivogabe)
    on Jan 25, 2016
    Contributor

    Allow for short hand module declarations:

    declare module "foo";

    to be equivalent to:

    declare module "foo" {
    var _temp: any;
    export = _temp;
}

    I think that this doesn't cover all cases, as this fails currently:

    declare module "foo" {
    var _tmp: any;
    export = _tmp;
}
declare module "bar" {
    import { x } from "foo"; // Error: Module foo has no exported member x
    import y from "foo"; // Error: Module foo has no default export
}

  8. mhegazy commented on Jan 25, 2016

    @mhegazy
    Mohamed Hegazy (mhegazy)
    on Jan 25, 2016
    ContributorAuthor

    thanks Ivo Gabe de Wolff (@ivogabe). the idea is you can use this module in any way you want and you just get any with no error. So the proposal should be updated to:

    declare module "foo" {
    var _temp: any;
    export = _temp;
    export default _temp;
}

  9. amcdnl commented on Jan 26, 2016

    @amcdnl
    Austin (amcdnl)
    on Jan 26, 2016

    I like the idea, but I think 2.0 is too far for this. This can help to solve so many issues the community has with lack of typings/etc.

  10. kitsonk commented on Jan 26, 2016

    @kitsonk
    Kitson Kelly (kitsonk)
    on Jan 26, 2016
    Contributor

    Thanks, this certainly address my use cases!

    Austin (@amcdnl), 2.0 is the next release after what is currently being stabilised as feature complete.

  11. geirsagberg commented on Jan 26, 2016

    @geirsagberg
    Geir Sagberg (geirsagberg)
    on Jan 26, 2016

    This is great! (GitHub really needs an upvote button.)

  12. jack4it commented on Jan 26, 2016

    @jack4it
    Jack Ma (jack4it)
    on Jan 26, 2016

    Two questions:

    • Are the current proposals able to cover the following scenario?
    import "xyz.less";

    Can I do this?

    declare module "xyz.less";
    • Will this syntax be one of the proposals?
    import template: string from "template.html";

  13. kitsonk commented on Jan 26, 2016

    @kitsonk
    Kitson Kelly (kitsonk)
    on Jan 26, 2016
    Contributor

    Jack Ma (@jack4it) if I understand the proposal correct:

    declare module "xyz.less";

    Would automagically make the import xyz from 'xyz.less' or import * as xyz from 'xyz.less' as type any. If you are just importing for side effects, like in your first statement, it is entirely up to what module loader you are using and how it is configured. Almost any module loader will require some sort of plugin (though obviously using NodeJS's registry can absolve people from having to consider this, but that doesn't make for very "portable" code).

    If you wanted the last to work, you would want to declare an ambient module like this:

    declare module '*.html' {
    const template: string;
    export default template;
}

    And you module loader would have to ensure that it process things appropriately.

    Personally, I think any more automagic behaviour would be dangerous.

  14. mhegazy commented on Jan 26, 2016

    @mhegazy
    Mohamed Hegazy (mhegazy)
    on Jan 26, 2016
    ContributorAuthor

    Will this syntax be one of the proposals?
    import template: string from "template.html";

    No. 1. is it makes it much harder to update your definitions later on as now you have sprinkled template: string throughout your code base, and 2. type annotations will need to be supported on all import forms not only default imports import d from "mod" but for namespace, and property imports, and that would add yet another variant to the import syntax, and we already have plenty.

  15. 54 remaining items

  16. mayerwin commented on Nov 21, 2016

    @mayerwin
    mayerwin
    on Nov 21, 2016

    Mohamed Hegazy (@mhegazy) Thanks 👍, I wasn't aware of the possibility to declare the whole module as any. It works. It would deserve to be highlighted more to help people know how easily they can tap into the JS ecosystem if they make the move to TS.

  17. mhegazy commented on Nov 21, 2016

    @mhegazy
    Mohamed Hegazy (mhegazy)
    on Nov 21, 2016
    ContributorAuthor

    you can find short-hand module declarations in:
    http://www.typescriptlang.org/docs/handbook/modules.html#shorthand-ambient-modules
    and in http://www.typescriptlang.org/docs/release-notes/typescript-2.0.html#shorthand-ambient-module-declarations

  18. wenbaofu commented on Feb 1, 2017

    @wenbaofu
    奔跑在路上 (wenbaofu)
    on Feb 1, 2017

    Mohamed Hegazy (@mhegazy) : hi , I had a question about this issue
    I try like this:
    in file.ts I write

    /// <reference path="require.d.ts" />
import JsonInfo from "json!files.json";

    I am not sure /// need or not

    then I new a file called require.d.ts

    declare module 'json!*' {
    const value: any;
    export default value;
}

    and the files.json is in base dir like below

    index.html
files.json
app/
   -  file.ts
   -  require.d.ts

    and I get below error
    image
    image

    but I can access the json file
    image

    I check the https://www.bountysource.com/issues/41187251-ambient-module-declarations-with-wildcards-giving-errors-official-docs-example-not-working
    and http://www.typescriptlang.org/docs/handbook/modules.html#shorthand-ambient-modules

    now I have no answer,hope your reply,tks

  20. wenbaofu commented on Feb 1, 2017

    @wenbaofu
    奔跑在路上 (wenbaofu)
    on Feb 1, 2017

    Andy (Andrewkraft) (@Andy-MS) : thank you first for answer

    you mean systemjs (module loader) not support?

    now I just use sample of hero to test json,I think loader maybe ok

    this is my config

    (function (global) {
    System.config({
        paths: {
            // paths serve as alias
            'npm:': 'node_modules/'
        },
        // map tells the System loader where to look for things
        map: {
            // our app is within the app folder
            app: 'app',
            // angular bundles
            '@angular/core': 'npm:@angular/core/bundles/core.umd.js',
            '@angular/common': 'npm:@angular/common/bundles/common.umd.js',
            '@angular/compiler': 'npm:@angular/compiler/bundles/compiler.umd.js',
            '@angular/platform-browser': 'npm:@angular/platform-browser/bundles/platform-browser.umd.js',
            '@angular/platform-browser-dynamic': 'npm:@angular/platform-browser-dynamic/bundles/platform-browser-dynamic.umd.js',
            '@angular/http': 'npm:@angular/http/bundles/http.umd.js',
            '@angular/router': 'npm:@angular/router/bundles/router.umd.js',
            '@angular/forms': 'npm:@angular/forms/bundles/forms.umd.js',
            // other libraries
            'rxjs':                      'npm:rxjs',
            'angular-in-memory-web-api': 'npm:angular-in-memory-web-api',
        },
        // packages tells the System loader how to load when no filename and/or no extension
        packages: {
            app: {
                main: './app.module.js',
                defaultExtension: 'js'
            },
            rxjs: {
                defaultExtension: 'js'
            },
            'angular-in-memory-web-api': {
                main: './index.js',
                defaultExtension: 'js'
            }
        }
    });

        "rxjs": "5.1.0",
    "systemjs": "0.20.5",
    "zone.js": "^0.6.25",
    "json-loader" : "^0.5.4"

    pls help check if systemjs don't support or not or other problem?

  21. aluanhaddad commented on Feb 1, 2017

    @aluanhaddad
    Aluan Haddad (aluanhaddad)
    on Feb 1, 2017
    Contributor

    SystemJS uses postfix plugin syntax: e.g

    import JsonInfo from "files.json!node_modules/json-loader/index.js";

    There has been discussion of supporting postfix and prefix notation but I do not believe it is currently supported.

    See systemjs/systemjs#1092

  22. aluanhaddad commented on Feb 1, 2017

    @aluanhaddad
    Aluan Haddad (aluanhaddad)
    on Feb 1, 2017
    Contributor

    Note that using package configuration as in

    packages: {
  app: {
    main: './app.module.js',
    defaultExtension: 'js',
    meta: {
      '*.json': {
        loader: 'my-loader'
      }
    }
  },
  ....

    with no plugin specifier as in

    import JsonInfo from 'files.json';

    is the preferred approach

  23. wenbaofu commented on Feb 1, 2017

    @wenbaofu
    奔跑在路上 (wenbaofu)
    on Feb 1, 2017

    Aluan Haddad (@aluanhaddad) : if like

    meta: {
      '*.json': {
        loader: 'my-loader'
      }
      import JsonInfo from 'files.json';

    will give the error with cannot find the module "files.json"

    image

    and json-loader is same
    image

  25. wenbaofu commented on Feb 1, 2017

    @wenbaofu
    奔跑在路上 (wenbaofu)
    on Feb 1, 2017

    Andy (Andrewkraft) (@Andy-MS) : yeah,it works(not give 404 error) , but when I print it , give undefined; when I give complex json, like { "name" : "test"}, then it will printf
    image

    image

    file.ts

    import JsonInfo from "files.json"; 
console.log(JsonInfo);

    files.json

    {
  id : 3
}

    module

    declare module '*.json' {
    const value: any;
    export default value;
}

    systemjs

    meta: {
            '*.json': {
                loader: 'my-loader'
                }
            }

  26. aluanhaddad commented on Feb 1, 2017

    @aluanhaddad
    Aluan Haddad (aluanhaddad)
    on Feb 1, 2017
    Contributor

    That is invalid JSON.

  27. drewlsvern commented on Mar 9, 2017

    @drewlsvern
    Joel Drewlo (drewlsvern)
    on Mar 9, 2017

    I'm not sure if anyone solved this, but I was able to get it to work using 奔跑在路上 (@wenbaofu) examples above. I just provided it valid json and used systemjs-plugin-json as the loader.

  28. mprast
    added a commit that references this issue on Mar 23, 2017

    🔧 add declarations.d.ts :/

    807e8f3

  29. Jack-Works commented on May 27, 2017

    @Jack-Works
    Jack Works (Jack-Works)
    on May 27, 2017
    Contributor

    Umm, can I do something more differently?
    Like

    declare module "*.module.js" {
	var loader: AsyncModuleLoader
	export = loader
}

    I use this type of declaration to type async module(by webpack), but not success

  30. microsoft
    locked and limited conversation to collaborators on Jun 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CommittedThe team has roadmapped this issueFixedA PR has been merged for this issueSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions