Why am I getting an error “Object literal may only specify known properties”?












41















I just upgraded from TypeScript 1.5 to the latest and I'm seeing an error in my code:



interface Options {
/* ... others ... */
callbackOnLocationHash?: boolean;
}

function f(opts: Options) { /* ... */ }

// Error: Object literal may only specify known properties,
// and 'callbackOnLoactionHash'does not exist in type 'Options'.
f( { callbackOnLoactionHash: false });


Code looks fine to me. What's wrong?



(Alternative universe version: I recognize the typo, and I really did mean to write that. What should I do to remove the error?)










share|improve this question


















  • 1





    For visitors, this is because of TypeScript's concept of freshness: basarat.gitbooks.io/typescript/content/docs/types/…

    – basarat
    Aug 5 '15 at 0:17
















41















I just upgraded from TypeScript 1.5 to the latest and I'm seeing an error in my code:



interface Options {
/* ... others ... */
callbackOnLocationHash?: boolean;
}

function f(opts: Options) { /* ... */ }

// Error: Object literal may only specify known properties,
// and 'callbackOnLoactionHash'does not exist in type 'Options'.
f( { callbackOnLoactionHash: false });


Code looks fine to me. What's wrong?



(Alternative universe version: I recognize the typo, and I really did mean to write that. What should I do to remove the error?)










share|improve this question


















  • 1





    For visitors, this is because of TypeScript's concept of freshness: basarat.gitbooks.io/typescript/content/docs/types/…

    – basarat
    Aug 5 '15 at 0:17














41












41








41


13






I just upgraded from TypeScript 1.5 to the latest and I'm seeing an error in my code:



interface Options {
/* ... others ... */
callbackOnLocationHash?: boolean;
}

function f(opts: Options) { /* ... */ }

// Error: Object literal may only specify known properties,
// and 'callbackOnLoactionHash'does not exist in type 'Options'.
f( { callbackOnLoactionHash: false });


Code looks fine to me. What's wrong?



(Alternative universe version: I recognize the typo, and I really did mean to write that. What should I do to remove the error?)










share|improve this question














I just upgraded from TypeScript 1.5 to the latest and I'm seeing an error in my code:



interface Options {
/* ... others ... */
callbackOnLocationHash?: boolean;
}

function f(opts: Options) { /* ... */ }

// Error: Object literal may only specify known properties,
// and 'callbackOnLoactionHash'does not exist in type 'Options'.
f( { callbackOnLoactionHash: false });


Code looks fine to me. What's wrong?



(Alternative universe version: I recognize the typo, and I really did mean to write that. What should I do to remove the error?)







typescript






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Aug 4 '15 at 17:55









Ryan CavanaughRyan Cavanaugh

99.6k27170179




99.6k27170179








  • 1





    For visitors, this is because of TypeScript's concept of freshness: basarat.gitbooks.io/typescript/content/docs/types/…

    – basarat
    Aug 5 '15 at 0:17














  • 1





    For visitors, this is because of TypeScript's concept of freshness: basarat.gitbooks.io/typescript/content/docs/types/…

    – basarat
    Aug 5 '15 at 0:17








1




1





For visitors, this is because of TypeScript's concept of freshness: basarat.gitbooks.io/typescript/content/docs/types/…

– basarat
Aug 5 '15 at 0:17





For visitors, this is because of TypeScript's concept of freshness: basarat.gitbooks.io/typescript/content/docs/types/…

– basarat
Aug 5 '15 at 0:17












1 Answer
1






active

oldest

votes


















95














As of TypeScript 1.6, properties in object literals that do not have a corresponding property in the type they're being assigned to are flagged as errors.



Usually this error means you have a bug (typically a typo) in your code, or in the definition file. The right fix in this case would be to fix the typo. In the question, the property callbackOnLoactionHash is incorrect and should have been callbackOnLocationHash (note the mis-spelling of "Location").



This change also required some updates in definition files, so you should get the latest version of the .d.ts for any libraries you're using.



Example:



interface TextOptions {
alignment?: string;
color?: string;
padding?: number;
}
function drawText(opts: TextOptions) { ... }
drawText({ align: 'center' }); // Error, no property 'align' in 'TextOptions'


But I meant to do that



There are a few cases where you may have intended to have extra properties in your object. Depending on what you're doing, there are several appropriate fixes



Type-checking only some properties



Sometimes you want to make sure a few things are present and of the correct type, but intend to have extra properties for whatever reason. Type assertions (<T>v or v as T) do not check for extra properties, so you can use them in place of a type annotation:



interface Options {
x?: string;
y?: number;
}

// Error, no property 'z' in 'Options'
let q1: Options = { x: 'foo', y: 32, z: 100 };
// OK
let q2 = { x: 'foo', y: 32, z: 100 } as Options;
// Still an error (good):
let q3 = { x: 100, y: 32, z: 100 } as Options;


These properties and maybe more



Some APIs take an object and dynamically iterate over its keys, but have 'special' keys that need to be of a certain type. Adding a string indexer to the type will disable extra property checking



Before



interface Model {
name: string;
}
function createModel(x: Model) { ... }

// Error
createModel({name: 'hello', length: 100});


After



interface Model {
name: string;
[others: string]: any;
}
function createModel(x: Model) { ... }

// OK
createModel({name: 'hello', length: 100});


This is a dog or a cat or a horse, not sure yet



interface Animal { move; }
interface Dog extends Animal { woof; }
interface Cat extends Animal { meow; }
interface Horse extends Animal { neigh; }

let x: Animal;
if(...) {
x = { move: 'doggy paddle', woof: 'bark' };
} else if(...) {
x = { move: 'catwalk', meow: 'mrar' };
} else {
x = { move: 'gallop', neigh: 'wilbur' };
}


Two good solutions come to mind here



Specify a closed set for x



// Removes all errors
let x: Dog|Cat|Horse;


or Type assert each thing



// For each initialization
x = { move: 'doggy paddle', woof: 'bark' } as Dog;


This type is sometimes open and sometimes not



A clean solution to the "data model" problem using intersection types:



interface DataModelOptions {
name?: string;
id?: number;
}
interface UserProperties {
[key: string]: any;
}
function createDataModel(model: DataModelOptions & UserProperties) {
/* ... */
}
// findDataModel can only look up by name or id
function findDataModel(model: DataModelOptions) {
/* ... */
}
// OK
createDataModel({name: 'my model', favoriteAnimal: 'cat' });
// Error, 'ID' is not correct (should be 'id')
findDataModel({ ID: 32 });


See also https://github.com/Microsoft/TypeScript/issues/3755






share|improve this answer

























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f31816061%2fwhy-am-i-getting-an-error-object-literal-may-only-specify-known-properties%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    95














    As of TypeScript 1.6, properties in object literals that do not have a corresponding property in the type they're being assigned to are flagged as errors.



    Usually this error means you have a bug (typically a typo) in your code, or in the definition file. The right fix in this case would be to fix the typo. In the question, the property callbackOnLoactionHash is incorrect and should have been callbackOnLocationHash (note the mis-spelling of "Location").



    This change also required some updates in definition files, so you should get the latest version of the .d.ts for any libraries you're using.



    Example:



    interface TextOptions {
    alignment?: string;
    color?: string;
    padding?: number;
    }
    function drawText(opts: TextOptions) { ... }
    drawText({ align: 'center' }); // Error, no property 'align' in 'TextOptions'


    But I meant to do that



    There are a few cases where you may have intended to have extra properties in your object. Depending on what you're doing, there are several appropriate fixes



    Type-checking only some properties



    Sometimes you want to make sure a few things are present and of the correct type, but intend to have extra properties for whatever reason. Type assertions (<T>v or v as T) do not check for extra properties, so you can use them in place of a type annotation:



    interface Options {
    x?: string;
    y?: number;
    }

    // Error, no property 'z' in 'Options'
    let q1: Options = { x: 'foo', y: 32, z: 100 };
    // OK
    let q2 = { x: 'foo', y: 32, z: 100 } as Options;
    // Still an error (good):
    let q3 = { x: 100, y: 32, z: 100 } as Options;


    These properties and maybe more



    Some APIs take an object and dynamically iterate over its keys, but have 'special' keys that need to be of a certain type. Adding a string indexer to the type will disable extra property checking



    Before



    interface Model {
    name: string;
    }
    function createModel(x: Model) { ... }

    // Error
    createModel({name: 'hello', length: 100});


    After



    interface Model {
    name: string;
    [others: string]: any;
    }
    function createModel(x: Model) { ... }

    // OK
    createModel({name: 'hello', length: 100});


    This is a dog or a cat or a horse, not sure yet



    interface Animal { move; }
    interface Dog extends Animal { woof; }
    interface Cat extends Animal { meow; }
    interface Horse extends Animal { neigh; }

    let x: Animal;
    if(...) {
    x = { move: 'doggy paddle', woof: 'bark' };
    } else if(...) {
    x = { move: 'catwalk', meow: 'mrar' };
    } else {
    x = { move: 'gallop', neigh: 'wilbur' };
    }


    Two good solutions come to mind here



    Specify a closed set for x



    // Removes all errors
    let x: Dog|Cat|Horse;


    or Type assert each thing



    // For each initialization
    x = { move: 'doggy paddle', woof: 'bark' } as Dog;


    This type is sometimes open and sometimes not



    A clean solution to the "data model" problem using intersection types:



    interface DataModelOptions {
    name?: string;
    id?: number;
    }
    interface UserProperties {
    [key: string]: any;
    }
    function createDataModel(model: DataModelOptions & UserProperties) {
    /* ... */
    }
    // findDataModel can only look up by name or id
    function findDataModel(model: DataModelOptions) {
    /* ... */
    }
    // OK
    createDataModel({name: 'my model', favoriteAnimal: 'cat' });
    // Error, 'ID' is not correct (should be 'id')
    findDataModel({ ID: 32 });


    See also https://github.com/Microsoft/TypeScript/issues/3755






    share|improve this answer






























      95














      As of TypeScript 1.6, properties in object literals that do not have a corresponding property in the type they're being assigned to are flagged as errors.



      Usually this error means you have a bug (typically a typo) in your code, or in the definition file. The right fix in this case would be to fix the typo. In the question, the property callbackOnLoactionHash is incorrect and should have been callbackOnLocationHash (note the mis-spelling of "Location").



      This change also required some updates in definition files, so you should get the latest version of the .d.ts for any libraries you're using.



      Example:



      interface TextOptions {
      alignment?: string;
      color?: string;
      padding?: number;
      }
      function drawText(opts: TextOptions) { ... }
      drawText({ align: 'center' }); // Error, no property 'align' in 'TextOptions'


      But I meant to do that



      There are a few cases where you may have intended to have extra properties in your object. Depending on what you're doing, there are several appropriate fixes



      Type-checking only some properties



      Sometimes you want to make sure a few things are present and of the correct type, but intend to have extra properties for whatever reason. Type assertions (<T>v or v as T) do not check for extra properties, so you can use them in place of a type annotation:



      interface Options {
      x?: string;
      y?: number;
      }

      // Error, no property 'z' in 'Options'
      let q1: Options = { x: 'foo', y: 32, z: 100 };
      // OK
      let q2 = { x: 'foo', y: 32, z: 100 } as Options;
      // Still an error (good):
      let q3 = { x: 100, y: 32, z: 100 } as Options;


      These properties and maybe more



      Some APIs take an object and dynamically iterate over its keys, but have 'special' keys that need to be of a certain type. Adding a string indexer to the type will disable extra property checking



      Before



      interface Model {
      name: string;
      }
      function createModel(x: Model) { ... }

      // Error
      createModel({name: 'hello', length: 100});


      After



      interface Model {
      name: string;
      [others: string]: any;
      }
      function createModel(x: Model) { ... }

      // OK
      createModel({name: 'hello', length: 100});


      This is a dog or a cat or a horse, not sure yet



      interface Animal { move; }
      interface Dog extends Animal { woof; }
      interface Cat extends Animal { meow; }
      interface Horse extends Animal { neigh; }

      let x: Animal;
      if(...) {
      x = { move: 'doggy paddle', woof: 'bark' };
      } else if(...) {
      x = { move: 'catwalk', meow: 'mrar' };
      } else {
      x = { move: 'gallop', neigh: 'wilbur' };
      }


      Two good solutions come to mind here



      Specify a closed set for x



      // Removes all errors
      let x: Dog|Cat|Horse;


      or Type assert each thing



      // For each initialization
      x = { move: 'doggy paddle', woof: 'bark' } as Dog;


      This type is sometimes open and sometimes not



      A clean solution to the "data model" problem using intersection types:



      interface DataModelOptions {
      name?: string;
      id?: number;
      }
      interface UserProperties {
      [key: string]: any;
      }
      function createDataModel(model: DataModelOptions & UserProperties) {
      /* ... */
      }
      // findDataModel can only look up by name or id
      function findDataModel(model: DataModelOptions) {
      /* ... */
      }
      // OK
      createDataModel({name: 'my model', favoriteAnimal: 'cat' });
      // Error, 'ID' is not correct (should be 'id')
      findDataModel({ ID: 32 });


      See also https://github.com/Microsoft/TypeScript/issues/3755






      share|improve this answer




























        95












        95








        95







        As of TypeScript 1.6, properties in object literals that do not have a corresponding property in the type they're being assigned to are flagged as errors.



        Usually this error means you have a bug (typically a typo) in your code, or in the definition file. The right fix in this case would be to fix the typo. In the question, the property callbackOnLoactionHash is incorrect and should have been callbackOnLocationHash (note the mis-spelling of "Location").



        This change also required some updates in definition files, so you should get the latest version of the .d.ts for any libraries you're using.



        Example:



        interface TextOptions {
        alignment?: string;
        color?: string;
        padding?: number;
        }
        function drawText(opts: TextOptions) { ... }
        drawText({ align: 'center' }); // Error, no property 'align' in 'TextOptions'


        But I meant to do that



        There are a few cases where you may have intended to have extra properties in your object. Depending on what you're doing, there are several appropriate fixes



        Type-checking only some properties



        Sometimes you want to make sure a few things are present and of the correct type, but intend to have extra properties for whatever reason. Type assertions (<T>v or v as T) do not check for extra properties, so you can use them in place of a type annotation:



        interface Options {
        x?: string;
        y?: number;
        }

        // Error, no property 'z' in 'Options'
        let q1: Options = { x: 'foo', y: 32, z: 100 };
        // OK
        let q2 = { x: 'foo', y: 32, z: 100 } as Options;
        // Still an error (good):
        let q3 = { x: 100, y: 32, z: 100 } as Options;


        These properties and maybe more



        Some APIs take an object and dynamically iterate over its keys, but have 'special' keys that need to be of a certain type. Adding a string indexer to the type will disable extra property checking



        Before



        interface Model {
        name: string;
        }
        function createModel(x: Model) { ... }

        // Error
        createModel({name: 'hello', length: 100});


        After



        interface Model {
        name: string;
        [others: string]: any;
        }
        function createModel(x: Model) { ... }

        // OK
        createModel({name: 'hello', length: 100});


        This is a dog or a cat or a horse, not sure yet



        interface Animal { move; }
        interface Dog extends Animal { woof; }
        interface Cat extends Animal { meow; }
        interface Horse extends Animal { neigh; }

        let x: Animal;
        if(...) {
        x = { move: 'doggy paddle', woof: 'bark' };
        } else if(...) {
        x = { move: 'catwalk', meow: 'mrar' };
        } else {
        x = { move: 'gallop', neigh: 'wilbur' };
        }


        Two good solutions come to mind here



        Specify a closed set for x



        // Removes all errors
        let x: Dog|Cat|Horse;


        or Type assert each thing



        // For each initialization
        x = { move: 'doggy paddle', woof: 'bark' } as Dog;


        This type is sometimes open and sometimes not



        A clean solution to the "data model" problem using intersection types:



        interface DataModelOptions {
        name?: string;
        id?: number;
        }
        interface UserProperties {
        [key: string]: any;
        }
        function createDataModel(model: DataModelOptions & UserProperties) {
        /* ... */
        }
        // findDataModel can only look up by name or id
        function findDataModel(model: DataModelOptions) {
        /* ... */
        }
        // OK
        createDataModel({name: 'my model', favoriteAnimal: 'cat' });
        // Error, 'ID' is not correct (should be 'id')
        findDataModel({ ID: 32 });


        See also https://github.com/Microsoft/TypeScript/issues/3755






        share|improve this answer















        As of TypeScript 1.6, properties in object literals that do not have a corresponding property in the type they're being assigned to are flagged as errors.



        Usually this error means you have a bug (typically a typo) in your code, or in the definition file. The right fix in this case would be to fix the typo. In the question, the property callbackOnLoactionHash is incorrect and should have been callbackOnLocationHash (note the mis-spelling of "Location").



        This change also required some updates in definition files, so you should get the latest version of the .d.ts for any libraries you're using.



        Example:



        interface TextOptions {
        alignment?: string;
        color?: string;
        padding?: number;
        }
        function drawText(opts: TextOptions) { ... }
        drawText({ align: 'center' }); // Error, no property 'align' in 'TextOptions'


        But I meant to do that



        There are a few cases where you may have intended to have extra properties in your object. Depending on what you're doing, there are several appropriate fixes



        Type-checking only some properties



        Sometimes you want to make sure a few things are present and of the correct type, but intend to have extra properties for whatever reason. Type assertions (<T>v or v as T) do not check for extra properties, so you can use them in place of a type annotation:



        interface Options {
        x?: string;
        y?: number;
        }

        // Error, no property 'z' in 'Options'
        let q1: Options = { x: 'foo', y: 32, z: 100 };
        // OK
        let q2 = { x: 'foo', y: 32, z: 100 } as Options;
        // Still an error (good):
        let q3 = { x: 100, y: 32, z: 100 } as Options;


        These properties and maybe more



        Some APIs take an object and dynamically iterate over its keys, but have 'special' keys that need to be of a certain type. Adding a string indexer to the type will disable extra property checking



        Before



        interface Model {
        name: string;
        }
        function createModel(x: Model) { ... }

        // Error
        createModel({name: 'hello', length: 100});


        After



        interface Model {
        name: string;
        [others: string]: any;
        }
        function createModel(x: Model) { ... }

        // OK
        createModel({name: 'hello', length: 100});


        This is a dog or a cat or a horse, not sure yet



        interface Animal { move; }
        interface Dog extends Animal { woof; }
        interface Cat extends Animal { meow; }
        interface Horse extends Animal { neigh; }

        let x: Animal;
        if(...) {
        x = { move: 'doggy paddle', woof: 'bark' };
        } else if(...) {
        x = { move: 'catwalk', meow: 'mrar' };
        } else {
        x = { move: 'gallop', neigh: 'wilbur' };
        }


        Two good solutions come to mind here



        Specify a closed set for x



        // Removes all errors
        let x: Dog|Cat|Horse;


        or Type assert each thing



        // For each initialization
        x = { move: 'doggy paddle', woof: 'bark' } as Dog;


        This type is sometimes open and sometimes not



        A clean solution to the "data model" problem using intersection types:



        interface DataModelOptions {
        name?: string;
        id?: number;
        }
        interface UserProperties {
        [key: string]: any;
        }
        function createDataModel(model: DataModelOptions & UserProperties) {
        /* ... */
        }
        // findDataModel can only look up by name or id
        function findDataModel(model: DataModelOptions) {
        /* ... */
        }
        // OK
        createDataModel({name: 'my model', favoriteAnimal: 'cat' });
        // Error, 'ID' is not correct (should be 'id')
        findDataModel({ ID: 32 });


        See also https://github.com/Microsoft/TypeScript/issues/3755







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Feb 14 at 15:37









        mega6382

        7,330143557




        7,330143557










        answered Aug 4 '15 at 17:55









        Ryan CavanaughRyan Cavanaugh

        99.6k27170179




        99.6k27170179
































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f31816061%2fwhy-am-i-getting-an-error-object-literal-may-only-specify-known-properties%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Monofisismo

            Angular Downloading a file using contenturl with Basic Authentication

            Olmecas