Webpack Autoreload for Unimported Files - go

I am working with WebAssmbly and Webpack together. My source wasm language is Go. How it works is that there is a webpack load rule that builds and imports the file to my project:
// index.js
import wasm from './main.go'
...
// webpack.config.js
...
rules: [
{
test: /\.go/,
use: ["golang-wasm-async-loader2"],
},
]
...
With watch mode enable, this works absolutely wonderfully for my main.go file. The issue arises when I change any other file. Go compiles all the files in a particular module to a single binary, so I only need to import the main file, and importing other files would just cause it to run multiple times (which I also don't want).
I was wondering if it was possible to force webpack to reload regardless of a file being imported or not?
I looked over at their watch docs however I did not find anything :(.
Thanks :)

Unfortunately, it sees seems that this is impossible to fix from webpack's user api. The only way to fix this is to change how the loader works.
Using The loader API, it is possible to add a context dependency or a generic dependency so that those files are watched for reloads as well :)

Related

Should I compile my react hook library, or publish only the ES6 code?

I have a very simple hook that I want to publish to npm, and I'm struggling to see why I should compile my hook at all. Let me first provide some context.
My hook depends only upon React.useState and React.useEffect. The purpose of this hook is to be used with my existing library: https://npmjs.com/package/simple-shared-state. As you can see, there's very little to this hook:
import { useEffect, useState } from "react";
export default (store, selectors) => {
const [state, setState] = useState([]);
useEffect(() => {
const unwatch = store.watchBatch(selectors, (array) => {
setState(array.slice());
});
return unwatch;
}, []);
return state;
};
I've looked at the create-react-hook cli tool, and tried it out, but I don't see how the included dev-dependencies are needed for my project. My hook is already usable in my mono-repo, where I added a folder, react-test-ground/, in which I provide a working app that I bootstrapped using CRA.
Concerning Testing:
If it makes sense to do, I can go the extra step of adding unit tests specifically for this hook, but at the moment, I can't see a strong need for this since the core of the functionality is in simple-shared-state, and all of that logic is already covered with pretty extensive tests.
I had a look at react-hooks-testing-library, and based on the "When to use this library" and "When not to use this library", it seems to me that my situation is one where I don't need to use this library. I think my hook is simple enough that the extra steps of adding more tests are hard to justify. Do you agree? Can you think of a reason why I should use react-hooks-testing-library?
Concerning compilation:
I can't see a strong reason to compile and minify my hook, since react app developers will almost exclusively be compiling their project from JSX anyway.
Summary
Given all of the above, is there any reason to do anything more than simply publish my hook, exactly as shown, on npm? Meaning, the package.json would include "main": "src/index.js", and no dist/ directory. React would go in the package.json under peerDependencies, and that's it. App developers would simply compile the source ES6 code of this hook into their bundle, and that's all.
Thanks in advance for taking the time to read and reply!
You can publish ES6 code.
The current js spec is ES2020. All runtimes should support all features from this spec.
Thus you need compile own code to latest standard. If user want to use your code on older runtimes(e.g. IE11) he can transpile all code in his build process.

Angular Dart - Using sass files

I am trying to set up sass with Angular Dart but I'm a bit lost and couldn't find a documentation past 2016 (a good one)
I currently have the following structure:
However I cannot reference a main.css file as it is not found and if in a component I put something like this
styleUrls: ['lib/assets/sass/main.scss']
The webdev serve command fails
My pubscpec is
dependencies:
angular: ^5.0.0
angular_components: ^0.9.0
bootstrap_sass: any
dev_dependencies:
angular_test: ^2.0.0
sass_builder: ^2.1.1
build_runner: ^0.10.0
build_test: ^0.10.2
build_web_compilers: ^0.4.0
mockito: ^3.0.0
test: ^1.3.2
I cannot figure out what's wrong and also the structure I should use
Should I put in my top component main.scss (or the compiler main.css) and do not set any other file reference or should I include it at every component? And also how can I generate this compiled file when I run webdev serve
Thanks,
Alexi
So the references for styleUrls should always be the compiled css not the Sass file. Also the Urls need to be either relative to the file, or package format. So either 'main.css' or 'package:your_project/assets/sass/main.css'
I would also suggest not having separate asset directories. I tend to find having the sass file next to the component to be easier to maintain.
AngularDart also has style encapsulation by default; meaning CSS won't leak outside of the Components by default. Given this I find it better to have the CSS local to that component and be next to that component. You'll find that is the pattern on the angular components, and gallery.
One small note on the components, and gallery. They use the pattern style.scss.css instead of style.css which breaks the convention of Sass. The reasoning behind it is so that we can quickly tell what the source of the CSS file was. Was it written by hand, or did it come from Sass. This is achieved by having different settings in the build.yaml file. I don't think you should do this for your project tho.

What is the root of an absolute path when importing a module in typescript?

I'm developing an app in typescript (in Visual Studio 2015) and have this basic file structure:
Solution
AppProject
Scripts
framework
Utils.ts
app
SomeApp.ts
tsconfig.json
Now within the app modules, I would like to reference the framework modules with an absolute path, so I would do something like this:
import { Utils } from '/Scripts/framework/Utils'
However this doesn't work.
I'm getting the red squiggly line and a "Cannot find module '/Scripts/framework/Utils'"
I works fine when doing a relative path, but the app is obviously more complex than what is shown, and I don't want to deal with stepping out multiple levels for my relative path.
I am using typescript 1.8 with the node module resolution strategy.
And webpack to compile and bundle it, if that matters
Unfortunately I couldn't find anything on that in the docs. So I traced the file system accesses performed by the compiler (TypeScript 2.5.2) when trying to resolve an import of an absolute path.
The result is that / always refers to the file system root. Regardless of compilerOptions like rootDir, rootDirs or baseUrl.

#testable import of Watch Extension module in Swift unit tests

I've noticed recently that #testable import doesn't seem to work for Watch Extension modules.
Here's what I've tried so far:
Create a new Xcode project with WatchKit app and include unit tests.
Open the auto created unit tests file and add #testable import ProjectName_WatchKit_Extension (after confirming that this is the correct module name in the extension's build settings). This gives a 'no such module' compiler error.
Confirm that 'Enable testability' is set to yes in Extension build settings.
Change name of Extension module to remove spaces
I am of course able to successfully unit test by adding the required files to the test target, but it feels like this should not be necessary.
Has anyone been able to successfully use #testable import with a Watch Extension? Is this something I should be able to do? Any help would be much appreciated.
From an Instagram library IGInterfaceDataTable: https://github.com/facebookarchive/IGInterfaceDataTable/tree/e5565a96c5a71ef7b849920adc34f880cc37dc03#testing
Since WKInterfaceTable objects must be initialized from storyboards, and
there is no mechanism yet to create a WatchKit storyboard in code, we cannot use
Xcode unit tests yet.
For now, tests are run manually by executing the ApplicationTests WatchKit
extension and ensuring that none of the asserts are fired.
This is a good question, I saw a similar issue was opened against Quick and Nimble testing framework which talks about the lack of support for watch kit extension testing. Take a look: https://github.com/Quick/Quick/issues/273.

xxxChanged methods dont' get called in JavaScript

I have two packages with several polymer custom elements.
Each package imports the other
One package contains elements that use or derive from the elements in the other package.
The other package uses the elements from the imported package just in the demo pages to make them more appealing.
There are no circular dependencies between elements.
In each package I have a folder 'example' that contains a demo page for each custom element.
I use the transformers configuration in pubspec.yaml and pub build to build the Javascript version of the demo pages.
(Because pub build doesn't yet support the example directory for entry points I created a symbolic link web that points to examples.)
When I execute pub build the examples are built and several of them work fine.
Not all though because there are limitations with transformers:
pub build with transformers doesn't support imported packages that have transformers configured in pubspec.yaml.
So my new approach was as suggested at the Dart web-ui group
I created a new package
The new package imports the two packages with the custom elements.
I symlinked all example files from the two custom elements packages to the web/ and web/src directory of the new package.
When I execute pub build all seems fine but
when I open the demo pages and debug them I see none of the xxxChanged methods of any of the custom elements get called (except when they are called explicitly from enteredView attached or ready).
Other methods like enteredView attached or ready are called though.
A diff between the files (about 14k size) showed several smaller differences but the most (about 98%) are equal.
This generated code (not minified) is not easy to decipher at least not for me and I found no hint what could have caused these differences.
Any Idea what can be the source of that problem?
When I add
transformers:
- polymer:
entry_points:
(without any entry_points)
to the pubspec.yaml of the custom elements packages all works fine in JavaScript too.
EDIT
related issues
generated JavaScript for polymer elements dosn't call xxxChanged for published attributes
add support for global transformers in code_transformers
polymer transformer can only be used on the application package and not on a library package
add support for dev_transformers

Resources