Skip to content

using noLib results in a number of intrinsic errors on empty file #3930

Closed
Closed
using noLib results in a number of intrinsic errors on empty file#3930
Labels
By DesignDeprecated - use "Working as Intended" or "Design Limitation" insteadQuestionAn issue which isn't directly actionable in code

Description

@jbrantly
James Brantly (jbrantly)
opened on Jul 20, 2015

This may be intended but wanted to bring it up for discussion. If I create an empty TypeScript file and call tsc app.ts everything is fine, but if I use tsc app.ts --noLib I see:

error TS2318: Cannot find global type 'Array'.
error TS2318: Cannot find global type 'Boolean'.
error TS2318: Cannot find global type 'Function'.
error TS2318: Cannot find global type 'IArguments'.
error TS2318: Cannot find global type 'Number'.
error TS2318: Cannot find global type 'Object'.
error TS2318: Cannot find global type 'RegExp'.
error TS2318: Cannot find global type 'String'.

So is the intention that if you use --noLib you must specify your own lib file that declares these items as a bare minimum?

Activity

  1. adidahiya commented on Jul 20, 2015

    @adidahiya
    Adi Dahiya (adidahiya)
    on Jul 20, 2015
    Contributor

    yeah, that's the idea of --noLib. it allows you to manually import the relevant lib.*.d.ts file for your project's environment rather than the default compiler lib.d.ts: https://github.com/Microsoft/TypeScript/tree/master/bin

  2. jbrantly commented on Jul 20, 2015

    @jbrantly
    James Brantly (jbrantly)
    on Jul 20, 2015
    Author

    I can see where my question could cause confusion, let me clarify. I understand that using --noLib means that lib.*.d.ts isn't imported. My question stems more from the fact that there are errors reported even though no code, for instance, uses Boolean or Number.

    To put it another way, there is (apparently) a rule somewhere that in order for an application to run without errors, even if that application is completely empty, interface Number {}, etc must exist, and I'm just trying to verify that's the intended behavior.

  3. Ryan Cavanaugh (RyanCavanaugh)
    added
    QuestionAn issue which isn't directly actionable in code
    on Jul 20, 2015

  4. RyanCavanaugh commented on Jul 20, 2015

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Jul 20, 2015
    Member

    So is the intention that if you use --noLib you must specify your own lib file that declares these items as a bare minimum?

    That's correct.

  5. Daniel Rosenwasser (DanielRosenwasser)
    added
    By DesignDeprecated - use "Working as Intended" or "Design Limitation" instead
    on Jul 21, 2015

  6. jbrantly commented on Jul 21, 2015

    @jbrantly
    James Brantly (jbrantly)
    on Jul 21, 2015
    Author

    Thanks.

  7. James Brantly (jbrantly)
    closed this as completedon Jul 21, 2015

  8. ilbmiller commented on Jul 21, 2015

    @ilbmiller
    ilbmiller
    on Jul 21, 2015
    1. Is there an 'minimum-lib.d.ts' available that has the minimum declarations to avoid the noisy TS 2318 errors when using the --noLib flag? Or should we just mine the lib.d.ts for the above 8 global types?
    2. Is there a way to specify 'use minimum-lib.d.ts' as a compiler flag? If not, I assume we have to manually put a ///<reference path="../../../defs/minimum-lib.d.ts" /> in every ts source file that uses one of the builtin types. (and compiling third-party libs/src will still generate the noisy TS2318 errors).

  9. RyanCavanaugh commented on Jul 21, 2015

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Jul 21, 2015
    Member

    Is there an 'minimum-lib.d.ts' available that has the minimum declarations

    src\lib\core.d.ts isn't fully minimal, but is much smaller than the full lib.d.ts

    Is there a way to specify 'use minimum-lib.d.ts' as a compiler flag? If not, I assume we have to manually put a /// in every ts source file that uses one of the builtin types.

    Why would you have to put this in every source file? The "flag" you're describing is equivalent to --noLib plus adding the path to the lib.d.ts file you want to the list of files you put on the commandline

  10. ilbmiller commented on Jul 21, 2015

    @ilbmiller
    ilbmiller
    on Jul 21, 2015

    Thx Ryan - but I'm a bit unclear as to how to go about 'adding the path to the lib.d.ts file you want'? Can you show an example invocation of 'tsc' that uses lib.core.d.ts in conjunction with a --noLib flag?
    In other words, here is my 1.5.3 experiment:

    touch foo.ts
tsc --noLib foo.ts      // get TS 2318 errors, so how do I get lib.core.d.ts in the 'path'?

    Of course, tsc foo.ts works just fine.

  11. ilbmiller commented on Jul 21, 2015

    @ilbmiller
    ilbmiller
    on Jul 21, 2015

    Aha - I was thinking 'path' as in 'java classpath', but it turns out that adding the lib.core.d.ts as one of the files to be compiled works. So the solution that worked for me is:

    tsc --noLib node_modules/typescript/bin/lib.core.d.ts   foo.ts

  12. binarez commented on Nov 3, 2015

    @binarez
    Stéphane Duguay (binarez)
    on Nov 3, 2015

    This makes it hard to compile programs in the browser using the Compiler API. Do I really need to fetch a copy of lib.core.d.ts using AJAX to feed it to the compiler? I'm not using any of those "global types" in the code I'm writing in the browser.

  13. CyrusNajmabadi commented on Nov 3, 2015

    @CyrusNajmabadi
    Cyrus Najmabadi (CyrusNajmabadi)
    on Nov 3, 2015
    Contributor

    Ryan Cavanaugh (@RyanCavanaugh)

    That's correct.

    I agree that that's how things have been implemented. But I think we could be a little more lax. We could make it so that these types are loaded on demand, and you only get the error once you hit a type that you need that isn't defined.

    Or, one way you could think about it was that there was always a file included with things like:

    interface Object { }
interface String { }
interface Number { }

    But that might be bad because how we'd have no structural checks at all.

    That said, maybe there isn't a lot of value for either of these. Using no-lib and not providing definitions for these types seems like a very uncommon thing to do.

  14. mhegazy commented on Nov 3, 2015

    @mhegazy
    Mohamed Hegazy (mhegazy)
    on Nov 3, 2015
    Contributor

    Stéphane Duguay (@binarez) it depends on what you want to do. if you want to show semantic errors, i.e. errors you would get from the compiler compiling on the command line, then you need the library file, other wise you will not get the correct errors.

    if, however, all you need is to get the output, i.e. transpiled JS, use ts.transpile instead, this does not require any semantic information, and no need for the library. see https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API#a-simple-transform-function for more details.

    it would help if you can shed some light on what you are trying to do, then we can help you more.

  15. aturpeinen commented on Dec 28, 2015

    @aturpeinen
    aturpeinen
    on Dec 28, 2015

    It would be good if everything would be inside one namespace/module. The namespace/module could be System, like in .Net. For example System.Array. Then if you have own class Array in your code it will not mess with System.Array.

  16. Manuel Lopez (jmlopez-rod)
    added 2 commits that reference this issue on Oct 25, 2016

    [chore:revert] forget using lib

    9987fe0

    [chore:revert] do not use lib in tsconfig

    8bc04d2
  17. 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

    By DesignDeprecated - use "Working as Intended" or "Design Limitation" insteadQuestionAn issue which isn't directly actionable in code

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions