chaijs / type-detect Goto Github PK

View Code? Open in Web Editor NEW

128.0 128.0 30.0 608 KB

Improved typeof detection for node.js and the browser.

License: MIT License

JavaScript 64.86% TypeScript 35.14%

type-detect's People

Contributors

Stargazers

Watchers

type-detect's Issues

Documentation for iterators, global, and browser environment missing

README.md mentions some features only in passing, without supporting documentation, thus leaving some features 'hidden' and unusable.

It mentions ES2015 support and documents many of the added APIs, but not all. Surprised at no mention of iterators I still found them supported in the code.

Return possibilities

  'Map Iterator'
  'Set Iterator'
  'Array Iterator'
  'String Iterator'

should be documented, though it may be hard to come up with easily understood examples on when these values are encountered. A combination of built-in objects and method calls ...?

    assert(type(new Map()).entries() === 'Map Iterator')
    assert(type(new Set()).entries() === 'Set Iterator')

While spelunking I found these browser/DOM-related values in the code:

return value	notes on source
'global'	(browser) window , (node) global , others...
'Location'	window.location
'Document'	window.document
'MimeTypeArray'	window.navigator.mimeTypes
'PluginArray'	window.navigator.plugins
'HTMLQuoteElement'	(IE fix) HTMLElement HTMLElement BLOCKQUOTE
'HTMLTableDataCellElement'	(W3C vs. WhatWG fix) HTMLElement TD
'HTMLTableHeaderCellElement'	(W3C vs. WhatWG fix) HTMLElement TH

After much scrolling of doc/code windows I think the above are all the missing parts.

If the mentions in passing of "global object", "iterators", "browsers" and "HTML elements" in README.md can be matched up with documented type string return values then readers will know how to use all the features this package provides.

Does not work with browserify

When running browserify to bundle test files using chai, I am getting the following error:

Cannot find module './lib-cov/type'

This is because index.js has a conditional require that is not supported by browserify. There was a similar problem in chai itself that has been fixed, is it possible to apply the same fix to type-detect too? See chaijs/chai#28 and chaijs/deep-eql#1.

requiring 4.0.4 leads to SyntaxError

With the update from version 4.0.3 to 4.0.3 I cannot require "type-detect/index.js" any longer, because it complains about a SyntaxError.

export default function typeDetect(obj) {
^^^^^^

v4.0.6 breaks node tests that manipulate global.window

Changes introduced by #129

After switching to use window rather than globalObject, tests running in node with a mock window (e.g. jsdom) will fail when manipulating (or deleting) global.window at runtime. I don't know how common this is, but it is a quick way to test modules intended to run on both client and server.

mocha --require config.js test

// config.js
const { JSDOM } = require('jsdom');
const { window } = new JSDOM('<!doctype html><html><body></body></html>');
global.window = window;

// test/foo.spec.js
const { expect } = require('chai');

describe('simplified example', function () {
  it('should perform assertions in a browser-like environment', function () {
    expect({}).to.eql({});
  });

  it('should not break when window removed', function () {
    global.window = null; // ideally reset afterward
    expect({}).to.eql({}); // boom!
    // TypeError: Cannot read property 'location' of null
    //  at typeDetect (node_modules/type-detect/type-detect.js:127:47)
  });
});

This could be avoided by chai users with greater care (and clear documentation), but I believe it was likely an unintended side effect of the changes made in #129.

Possible solutions:

Accept the new behavior but revert to patch and then republish as a breaking change with clear documentation around expected behavior.
Evaluate environment at runtime in the typeDetect function, rather than cached in the module. This will be slightly less efficient but will be accurate. It also raises the question as to whether all feature checks should be evaluated on every call as well.
Other?

'Unexpected token export' Issue using chai in last release

It looks like there is a breaking change. We have locked our version on chai but we now get the following error:

/src/node_modules/type-detect/index.js:49
export default function typeDetect(obj) {
^^^^^^

SyntaxError: Unexpected token export

Issues running tests locally

On my lightweight AWS EC2 instance with no browsers installed, it remains stuck at the following part when running the test suite with the new build process and plumbing in place:

type-detect@ test:browser /opt/code/type-detect
karma start --singleRun=true

02 11 2017 21:33:01.012:INFO [framework.detect-browsers]: The following browsers were detected on your system: []
02 11 2017 21:33:01.050:INFO [karma]: Karma v1.7.1 server started at http://0.0.0.0:9876/

Travis build is failing

Looks related to travis-ci/travis-ci#8836. There are suggestions of either adding sudo: required to the config, or adding the --no-sandbox flag to the karma launcher for Chrome.

15 01 2018 03:14:44.739:INFO [launcher]: Starting browser ChromeHeadless
15 01 2018 03:14:45.013:ERROR [launcher]: Cannot start ChromeHeadless
[0115/031444.860776:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /opt/google/chrome/chrome-sandbox is owned by root and has mode 4755.
Failed to generate minidump.

4.0.4 contains breaking change to ES6 modules

[email protected] uses ES6 modules in its main which causes it to throw the following error when run in node:

export default function typeDetect(obj) {
^^^^^^
SyntaxError: Unexpected token export

I assume this was accidental, since it's a massive breaking change in a patch release making chai unusable. You may wish to unpublish 4.0.4.

Requesting version bump

Hi, I'm trying to use chai 4.3.4 in an environment that is neither node.js or the browser, and it works fine except for the fact that the polyfill to detect the global object as of type-detect 4.0.5 does not work in my environment (global does not exist, and neither does self, but globalThis does). Recent changes in #142 would absolutely work for my case, but there's no npm package right now that would pick them up.

Could type-detect and Chai get version bumps with these recent changes? thank you

Several open Greenkeeper-PRs

@keithamus , @meeber
I was sleeping for a whole while in this project - sorry for that.

But I`ve awoken and found an awful lot of Greenkeeper-PRs having a failing build.
I want to tackle those PRs now but I want to talk a strategy with you first.

First of all, there is a lot of updated dependencies which simply fly around build-tooling. We could ask ourselves if we really need those updates.

Then there is a bunch of outdated PRs of updated dependncies. For example ESLint has PRs for laround 6 different Versions. For those, I would just close the old-version-PRs and only leave the newest ones - if we already gonna put work into this, then let's do it right.

That should already clear the field for a better overview.
What do you think?

AsyncFunction and GeneratorFunction issues

I think, tests should pass:

const type = require('type-detect');
const assert = require('assert');

const asyncFn = async () => {};
const generatorFn = function* generator () {};

function getTag(obj) {
  return Object.prototype.toString.call(obj).slice(8, -1);
}

assert(type(asyncFn) === getTag(asyncFn));
assert(type(generatorFn) === getTag(generatorFn));

Is it a bug? If not, you should add it to README.

Next steps?

@logicalparadox @keithamus
I was wondering how are the next steps here. Are you going to release a new version? Or you want me to move chai to the current master branch?

Also, I found one more little mistake in the docs:

assert(type(new String('hello')) === 'object'); -> that should be 'string'
Its probably easier now to fix that directly on master than for me doing a pull request. ;)

Symbol issue (lowercase)

The following assertion fails:

assert(type(Symbol()) === 'Symbol'); // AssertionError

It is taken from the README.md file. The actual result of the type-check is 'symbol' (lowercase)

So, type(Symbol()) !== Symbol.name.

v4.0.4 minor but breaking changes on node 6

export default function typeDetect(obj) {
^^^^^^
SyntaxError: Unexpected token export

We are still using node6 LTS and this morning, our tests (using chai) fails with this error.

Problem releasing new version

Merging #91 didn't trigger a release. Found this in the travis logs:

6.95s$ travis-after-all && npm run semantic-release
[travis-after-all] Job succeeded (40027526e0227d81659090077756bde5fb9776ff1d5e08fb38f991cd2a5144cc)
[travis-after-all] Waiting for 427.2, 427.3, 427.4 and 427.5 to be done...
[travis-after-all] Failed to parse JSON from "https://api.travis-ci.org/jobs/295118317".
Error: Cannot read property 'indexOf' of null

How to get in touch regarding a security concern

Hello 👋

I run a security community that finds and fixes vulnerabilities in OSS. A researcher (@austinoa18) has found a potential issue, which I would be eager to share with you.

Could you add a SECURITY.md file with an e-mail address for me to send further details to? GitHub recommends a security policy to ensure issues are responsibly disclosed, and it would help direct researchers in the future.

Looking forward to hearing from you 👍

(cc @huntr-helper)

Latest version breaks in nodejs

https://github.com/chaijs/type-detect/blob/master/rollup.conf.js#L17 seems to break type-detect when running in nodejs environment because it generates

export default function typeDetect(obj) {

which is not supported by nodejs

[documentation] state all the possible types in Readme

hi all,
This library introduces some types that don't exist in ES5 and I found it slightly annoying to do a guesswork, which type starts with capital letter and which does not.

I couldn't find the list of types in Chai documentation website. Even if it's there hidden somewhere, it would be nice to add the list of all types that this library produces in this library's README.

For example (with correct capitalisation):

string << lowercase
Object << uppercase
Function << uppercase
boolean << lowercase
...

and so on..

What do you think?

Type detect on native async functions returns "asyncfunction" on node instead of "function"

On node 8.1.0 (probably also on older versions supporting async functions) calling returns asyncfunction:

const typeDetect = require('type-detect');

typeDetect(async function() {})

I believe this is not correct and should return function since async functions are noting more than normal functions returning promises from the function user's PoV.

What are your thoughts on this?

SyntaxError: Unexpected token export after upgrading to version 4.0.4

Hello! After upgrading to version 4.0.4 I cannot run my mocha tests anymore. I am getting SyntaxError: Unexpected token export on the index.js file of the type-detect. Here is the full stack:

C:\Tools\nodejs\node.exe "\node_modules\mocha\bin_mocha" --ui bdd --reporter C:\Users\taakopa7.IntelliJIdea2017.2\config\plugins\NodeJS\js\mocha-intellij\lib\mochaIntellijReporter.js "\test\mytest.js" --grep "Test "
\node_modules\type-detect\index.js:49
export default function typeDetect(obj) {
^^^^^^
SyntaxError: Unexpected token export
at Object.exports.runInThisContext (vm.js:76:16)
at Module._compile (module.js:542:28)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (\node_modules\chai\lib\chai\utils\index.js:23:16)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (\node_modules\chai\lib\chai.js:25:12)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (\node_modules\chai\index.js:1:80)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object. (\test\mytest.js:2:12)

Why do {... if (obj === Object(obj)) return 'object'; ...} ?

Sorry in advance if the reason seems obvious to you and I am just bothering you. I can't sleep well at night with that line keep showing up in my head. Googling show nothing that could explain it. Is there any special case needs to be handled by that line?

`HTMLTableDataCellElement` and `HTMLTableHeaderCellElement` are no longer in spec.

We have specific conformance checks for td elements being HTMLTableDataCellElement and th being HTMLTableHeaderCellElement - as per what was (at the time) the WHATWG Spec.

However the WHATWG Spec has been aligned to the browsers (see whatwg/html#1125, whatwg/html#1115) and any implementation that was destined to reflect this has backed out. So we should too.

Proposal is to remove both of these conformance checks and change the tests to reflect this.

Relevant LOC:

type-detect/index.js

Lines 177 to 207 in f79e0e4

 /* ! Spec Conformance 

  * (https://html.spec.whatwg.org/#htmltabledatacellelement) 

  * WhatWG HTML$4.9.9 - The `td` element - Interface `HTMLTableDataCellElement` 

  * Note: Most browsers currently adher to the W3C DOM Level 2 spec 

  * (https://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-82915075) 

  * which suggests that browsers should use HTMLTableCellElement for 

  * both TD and TH elements. WhatWG separates these. 

  * Test: Object.prototype.toString.call(document.createElement('td')) 

  * - Chrome === "[object HTMLTableCellElement]" 

  * - Firefox === "[object HTMLTableCellElement]" 

  * - Safari === "[object HTMLTableCellElement]" 

  */ 

 if (obj instanceof globalObject.HTMLElement && obj.tagName === 'TD') { 

 return 'HTMLTableDataCellElement'; 

 } 

 /* ! Spec Conformance 

  * (https://html.spec.whatwg.org/#htmltableheadercellelement) 

  * WhatWG HTML$4.9.9 - The `td` element - Interface `HTMLTableHeaderCellElement` 

  * Note: Most browsers currently adher to the W3C DOM Level 2 spec 

  * (https://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-82915075) 

  * which suggests that browsers should use HTMLTableCellElement for 

  * both TD and TH elements. WhatWG separates these. 

  * Test: Object.prototype.toString.call(document.createElement('th')) 

  * - Chrome === "[object HTMLTableCellElement]" 

  * - Firefox === "[object HTMLTableCellElement]" 

  * - Safari === "[object HTMLTableCellElement]" 

  */ 

 if (obj instanceof globalObject.HTMLElement && obj.tagName === 'TH') { 

 return 'HTMLTableHeaderCellElement'; 

 }

These two tests will need to change (but we should keep them):

type-detect/test/dom.js

Lines 286 to 292 in f79e0e4

 it('HTMLTableDataCellElement', () => { 

 assert(type(document.createElement('TD')) === 'HTMLTableDataCellElement'); 

 }); 

 it('HTMLTableHeaderCellElement', () => { 

 assert(type(document.createElement('TH')) === 'HTMLTableHeaderCellElement'); 

 });

Automatic release failed

More info here: https://travis-ci.org/chaijs/type-detect/jobs/299299300

Build failing due to sauce tunnel issue

Sauce is reporting the error as being "Your test errored. No active tunnel found for identifier 1509755873974". That number looks to be milliseconds since epoch from here, but I think what we need is the Travis job number from here?

Clarify usage in browser case

When importing type-detect in the browser, the function is called 'typeDetect'

If the usage examples are followed as-is, the browser will throw an error indicating that type() is not defined.

In order to run the examples as written in the browser, the user should declare a variable type that refers to typeDetect(). An alternative would be to provide another set of browser-specific examples using typeDetect() instead of type(), but I think that would be overly verbose and confusing.

It fails with `yarn`

I did chai with yarn (yarn add chai -D) and it pulled type-detect v4.0.5. After that it breaks on mocha as it is not transpiled. I did same with npm install and it worked. I see transpiled file.

It is Node.JS v8.9.1, npm v5.5.1, yarn v1.2.1

export default function typeDetect(obj) {
^^^^^^

SyntaxError: Unexpected token export
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:599:28)
    at Object.Module._extensions..js (module.js:646:10)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Module.require (module.js:579:17)
    at require (internal/module.js:11:18)

Advice?

Release v4.0.5 needs ES6 modules syntax?

During my build I'm getting:

/usr/src/app/node_modules/type-detect/index.js:49
export default function typeDetect(obj) {
^^^^^^

SyntaxError: Unexpected token export
    at createScript (vm.js:74:10)
    at Object.runInThisContext (vm.js:116:10)
    at Module._compile (module.js:533:28)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)

It's intentional? Because it seems like huge change, not a minor patch – v4.0.3 used old module syntax.

Function issue (lowercase)

function is not primitive so you should definitely return 'Function' instead

ReferenceError: HTMLElement is not defined

Hello,
I'm using Webstorm to run Mocha tests (on react components) using Chai together with Enzyme, Sinon and Sinon-chai.

I'm doing something like this:
expect(ChildSpy).to.have.been.calledWithMatch({a:'a', b: 'b'}); that basically is the same as saying:
sinon.assert.calledWith(ChildSpy, sinon.match({a:'a', b: 'b'}));.

However I use it I receive and exception from this packages, exactly from this line:

ReferenceError: HTMLElement is not defined
    at typeDetect (node_modules/type-detect/index.js:159:24)
    at typeOf (node_modules/sinon/lib/sinon/util/core/typeOf.js:6:12)
    at Object.match (node_modules/sinon/lib/sinon/match.js:103:16)
    at Context.<anonymous> (test/main.js:106:45)

Apparently the HTMLElement used in this function is not defined.
Does that depend on the node version or maybe was this package conceived to run in the browser and not in node?

if (obj instanceof HTMLElement && obj.tagName === 'BLOCKQUOTE') {
    return 'HTMLQuoteElement';
}

Maybe there is a check somewhere to understand if we are in a browser or not but I could have make things difficult to check because before starting my tests I do this:

// Setup for enzyme: http://airbnb.io/enzyme/docs/guides/jsdom.html
const doc = jsdom.jsdom('<!doctype html><html><body></body></html>', {
  url: 'http://localhost'
});
const win = doc.defaultView;

// Setup for react test-utils 'renderIntoDocument':
// it requires window, window.document and window.document.createElement
// globally available before you can import React
global.document = doc;
global.window = win;
global.navigator = win.navigator;

So type-detect believes is in a browser when in fact it's not? 🤔

v4.0.5 contains pure ES2015 modules

$ grep version packages/postcss-tone-vars/node_modules/type-detect/package.json
  "version": "4.0.5"
$ grep export packages/postcss-tone-vars/node_modules/type-detect/index.js
export default function typeDetect(obj) {

Feels like it requires rebuild ;-(

const type = require('type-detect');
class ExtendedArray extends Array {
  get [Symbol.toStringTag]() {
    return 'ExtendedArray';
  }
}
console.log(type(new ExtendedArray())); //=> 'array'

My initial expectation was that I would receive back ExtendedArray through the use of Symbol.toStringTag, but the code returns array, from here. Is this intended?

	/* ! Spec Conformance
	* (https://html.spec.whatwg.org/#htmltabledatacellelement)
	* WhatWG HTML$4.9.9 - The `td` element - Interface `HTMLTableDataCellElement`
	* Note: Most browsers currently adher to the W3C DOM Level 2 spec
	* (https://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-82915075)
	* which suggests that browsers should use HTMLTableCellElement for
	* both TD and TH elements. WhatWG separates these.
	* Test: Object.prototype.toString.call(document.createElement('td'))
	* - Chrome === "[object HTMLTableCellElement]"
	* - Firefox === "[object HTMLTableCellElement]"
	* - Safari === "[object HTMLTableCellElement]"
	*/
	if (obj instanceof globalObject.HTMLElement && obj.tagName === 'TD') {
	return 'HTMLTableDataCellElement';
	}

	/* ! Spec Conformance
	* (https://html.spec.whatwg.org/#htmltableheadercellelement)
	* WhatWG HTML$4.9.9 - The `td` element - Interface `HTMLTableHeaderCellElement`
	* Note: Most browsers currently adher to the W3C DOM Level 2 spec
	* (https://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-82915075)
	* which suggests that browsers should use HTMLTableCellElement for
	* both TD and TH elements. WhatWG separates these.
	* Test: Object.prototype.toString.call(document.createElement('th'))
	* - Chrome === "[object HTMLTableCellElement]"
	* - Firefox === "[object HTMLTableCellElement]"
	* - Safari === "[object HTMLTableCellElement]"
	*/
	if (obj instanceof globalObject.HTMLElement && obj.tagName === 'TH') {
	return 'HTMLTableHeaderCellElement';
	}

	it('HTMLTableDataCellElement', () => {
	assert(type(document.createElement('TD')) === 'HTMLTableDataCellElement');
	});

	it('HTMLTableHeaderCellElement', () => {
	assert(type(document.createElement('TH')) === 'HTMLTableHeaderCellElement');
	});

chaijs / type-detect Goto Github PK

type-detect's People

Contributors

Stargazers

Watchers

Forkers

type-detect's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs