Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeError: assert is not a function #23

Open
miohtama opened this issue Apr 23, 2022 · 3 comments
Open

TypeError: assert is not a function #23

miohtama opened this issue Apr 23, 2022 · 3 comments

Comments

@miohtama
Copy link

miohtama commented Apr 23, 2022

I have been using assert-ts fine with different environments. However, now when running with Node v16.14.2 in SvelteKit with its Node.Js adapter for Trading Strategy frontend I am getting the following error:

import assert from 'assert-ts';

console.log("Assert is", assert);
assert(input, 'input number missing');
TypeError: assert is not a function

The assert object looks good based on console.log output:

Assert is {
  configureAssert: [Getter],
  testResetConfiguration: [Getter],
  assert: [Getter],
  default: [Function: hardAssert] { soft: [Function: softAssert] }
}

This happens only when running SvelteKit application using Node.js production build adapter, not when running it with Vite development server.

Will keep debugging. All tips welcome.

@miohtama
Copy link
Author

miohtama commented Apr 23, 2022

This has something to do with the default export. If you use the following syntax:

import { assert } from 'assert-ts';

The assert() works fine. In this case you get:

< Assert is [Function: hardAssert] { soft: [Function: softAssert] }

I suspect some kind of issue with TypeScript build pipeline or SvelteKit JavaScript transpiling.

miohtama added a commit to tradingstrategy-ai/trade-executor-frontend that referenced this issue Apr 23, 2022
miohtama added a commit to tradingstrategy-ai/frontend that referenced this issue Apr 23, 2022
@bjornegil
Copy link
Collaborator

@miohtama, thanks for reporting and debugging! I think it's useful to still support the default export/import, depending on your preferences (and environment). Do you have any proposals for changing the code, or should I close the issue?

@miohtama
Copy link
Author

I thin you can close it, but I feel this also should be reflected in the documentation somehow. I do not have a concrete proposal how, though, because I do not understand the context when default imports do not work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants