While reading this article earlier, I came across the following line of code:
import { run } from '#cycle/core';
Which led me to the following questions:
What is the significance of the # symbol, if any?
Is there a difference between import 'foo/bar' and import '#foo/bar'?
Is it a way to resolve a particular type of module?
I'm relatively new to ES6, although the import syntax seems pretty straightforward to me - except, in this case, for the cryptic presence of the # symbol.
I tried googling but couldn't find any information on Stack Overflow, MDN or elsewhere.
Right from the Getting Started docs:
Packages of the type #org/package are npm scoped packages, supported
if your npm installation is version 2.11 or higher. Check your npm
version with npm --version and upgrade in order to install Cycle.js.
In case you are not dealing with a DOM-interfacing web application,
you can omit #cycle/dom when installing.
Related
I'm seeing some API drift between the type declarations/definitions of a typescript DefinitelyTyped module (e.g. #types/prompts) and the javascript module it is meant to 'wrap'. How is one supposed to correctly pair versions for the the types package, and the version for the underlying javascript package?
Say I add a dependency on #types/prompts": "^2.0.14" in my package.json. How do I make sure I get the right version of javascript npm package that goes with it?
The npm package #types/prompts has no explicit dependency on the javascript module in its package.json, and there doesn't seem to be any mention of compatibility that I can see in the README.
All I've found is a loose comment in #types/prompts's index.d.ts mentioning:
// Type definitions for prompts 2.0
// Project: https://github.com/terkelg/prompts
...
Is there a convention we're supposed to follow? I'd be interested in hearing about a general approach, not necessarily just for this example.
References:
typescript types package: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/prompts
upstream javascript module: https://github.com/terkelg/prompts
In my experience, usually major and minor versions are being kept in sync between the upstream package and its #types package. Then the patch version would not match, due to the need of being able to fix a bug.
An example with react:
The current version of react is 17.0.2
The current version of #types/react is 17.0.37
The only part which isn't super clear is when a patch of the upstream package changes types. Is that change already applied in the types package?
So for example react decides to publish 17.0.3 which contains a non-breaking difference in types. How do we know if 17.0.37 includes that change? But for that, it's probably a better idea for react to actually publish 17.1.0 to address that new change.
I know it is a bad practice to use the import as well as require statements in the same file, but I heard it shouldn't cause any problems.
Why will my lambda fail then (when running yarn run local) and complain about an 'Unexpected Identifier' when encountering the import statement?
Here's the current codebase. The problem lies in the functions/edge.js file.
EDIT: I'm sorry I haven't clearly formulated my question. Replacing the import statement with the seemingly equivalent const middleware = require('#sapper/server'); results in an error: It can't find the module - with import it works perfectly fine, even during production.
Because AWS Lambdas run on node, and the version of node AWS Lambda use don't support import keyword.
More info on NodeJS plans to support import/export es6 (es2015) modules
EDIT: As #Michael states in the comments, you need to install the proper packages. Either by using npm or looking where the package should be (I guess you should follow sapper.svelte instructions properly). import would fail the same way as require as the package don't exists. Is not an "import vs require" problem, but a non-existent package problem.
I've built a JavaScript/TypeScript library that I want to work as:
A global variable when called from either JavaScript and TypeScript
Accessed via RequireJS when called from either JavaScript and TypeScript
Has full unit test coverage
This is a UMD packaged using Webpack and deployed as an NPM package here (https://www.npmjs.com/~typed-contract). If you want the whole source of the branch I'm working on, you can find it here https://github.com/randarp/typed-contract/tree/feature/Issue_5.1.
My problem is that I can't get it to work in all scenarios and my feeling is that the hyphen in the package name (i.e. typed-contract) is the culprit. Some examples:
In TypeScript, \Code\TypedContract.Specs\Contract.TypeScript.requireJS.spec.ts
If I use import { contract } from "typed-contract" then my unit tests fail, but the WebStorm transpiler says it's correct.
If I use import { contract } from "typedcontract" then my unit tests pass, but the transpiler says Error:(4, 26) TS2306:File 'C:/Projects/TypedContract/Code/typedcontract.d.ts' is not a module.
I have an external NodeJS application to test this. In that case:
If I use import {contract} from 'typed-contract' it works as expected
If I use import {contract} from 'typedcontract' it won't load the application because it can't find the NPM package under node_modules.
I'm starting to think I need to deprecate this package and start a new one without a hyphen unless somebody can give some clues as to what may be going on because my "programming by permutation" isn't working.
Well, after a few more failed attempts, I created a new package and deprecated the old one. It can now be found at:
https://www.npmjs.com/package/typedcontract.
I just couldn't get it to work in all scenarios with the hyphen, so this seemed like the best long term solution.
I'm starting to think I need to deprecate this package and start a new one without a hyphen
I should work with the -.
Don't trust WebStorm too much. TSC should be your single source of truth.
then my unit tests fail
Perhaps your unit tests are wrong then.
I have spent a long time simply trying to install React and React-DOM.
I start my script with:
var React = require('react');
var ReactDOM = require('react-dom');
I used Node and NPM to install into my project directory, and I can see they've been successfully installed in my NetBeans IDE. I open Project Setting->Javascript Libraries->NPM and I can see React v15.4.2 and React-DOM v15.4.2.
Despite this I still get the error:
ReferenceError: Can't find variable: require
(21:07:49:681 | error, javascript)
at global code (public_html/main.js:8:20)
If anyone has a suggestion then I would really appreciate it.
You can't use require() in the browser just yet (and the spec will be different from the RequireJS syntax anyway) . If you want to get started with React, I recommend you try create-react-app to begin with. As soon as you feel comfortable with the workflow, you can try to set up your own development and production environment, using Gulp, Browserify or the more popular Webpack module.
Hope that helps.
This won't work. Include your react.js and react-dom.js libraries from npm packages to the main page of your project (i.e. index.html). Also remember to add babel.js - it's not connected with your issue, just mentioning for the future.
I'm a newbie to Meteor.js and working on a project where I'm also using Redux so I added the kyutaekang:redux package. The problem is that I don't know how to import Redux to use it. I tried:
import { createStore } from 'redux';,
but when I start the app I get
[Error: Unable to fetch "redux". Only file URLs of the form file:/// allowed running in Node.].
Meteor does not yet support the ES2015 import out of the box (might be available in 1.3.0). Therefore, you will need a modern module bundler, as also described in the package's Readme file:
This assumes that you’re using npm package manager with a module bundler like Webpack or Browserify to consume CommonJS modules.
You can take a look at this excellent example by Adam Brodzinski to get you started.
Edit:
After taking a closer look at the package, it does not seem to contain any code.
Nonetheless, my recommendation about Adam's repo (or his other repo, pointed in the comments) still remains as a nice, clean implementation.