I am using TypeScript with React, and one of the things I want to achieve is background sync for offline support.
To enable typings for service worker, I have to include the WebWorker lib, but it conflicts with DOM lib and produces an error:
(25,1): Definitions of the following identifiers conflict with those in another file:
EventListenerOrEventListenerObject, BlobPart, HeadersInit, BodyInit,
RequestInfo, DOMHighResTimeStamp, PerformanceEntryList, PushMessageDataInit,
VibratePattern, BufferSource, DOMTimeStamp, FormDataEntryValue,
IDBValidKey, MessageEventSource, BinaryType, ClientTypes,
IDBCursorDirection, IDBRequestReadyState, IDBTransactionMode,
NotificationDirection, NotificationPermission, PushEncryptionKeyName,
PushPermissionState, ReferrerPolicy, RequestCache, RequestCredentials,
RequestDestination, RequestMode, RequestRedirect, ResponseType,
ServiceWorkerState, ServiceWorkerUpdateViaCache, VisibilityState,
WorkerType, XMLHttpRequestResponseType
So I am wondering if there is any workaround except for typing most of my arguments any.
You can split your project into multiple parts with separate tsconfig.json files: one part that includes the dom lib and one part that includes the webworker lib. You can make another part for common code that doesn't depend on either library. You can use project references to help automate the build. If this doesn't fully solve the problem, please update the question to describe the outstanding issues.
Related
I have a function I created called ENCODE-JSON-TO-STRING in my package called libray.
I wanted to replace my function with the function from cl-json. Which is also called ENCODE-JSON-TO-STRING.
I removed my function with fmakunbound.
However when I try to import cl-json I get the following error:
LIBRARY also shadows the following symbols:
(JSON:ENCODE-JSON-TO-STRING)
compilation failed
My goal is to completely erase the existance of LIBRARY:ENCODE-JSON-TO-STRING
How do I achieve that?
Package importing looks on symbols, and does not care whether they are bound or fbound or not.
The term to remove symbol from package is unintern, and the function to achieve it has same name - unintern, so what you look for should be (unintern 'LIBRARY:ENCODE-JSON-TO-STRING 'library).
You may also want to have a look on shadowing-import and package concepts in general.
Of course, simplest way may be just simply restart and rebuild your system from clean image without creating LIBRARY:ENCODE-JSON-TO-STRING at all.
I am new to React development and have been using named and default imports. I need to know whether importing a default export and using its named exports by referencing it such as
import * as R from 'ramda';
...
R.map(...),
R.propEq(..,..),
R.equals(..,..),
R.pipe(,,,)
or importing its named exports such as
import {map, propEq, equals, pipe} from 'ramda';
...
map(...),
propEq(..,..),
equals(..,..),
pipe(,,,)
creates a difference in build size?
Does compiler builds with complete ramda lib in first case and only the required functions in second? Is it intelligent enough and checks which of the functions are used in the code and only keeps those in the build?
I have tested it on sample of 2-3 named and default export functions of ramda and build size is same. Will it scale the same way?
This is a webpack question as far as i know and not a Reactjs.
The quick answer for most libraries is that it does not make a difference on bundle size, but it is good practice not to load the whole library every time you need just one part.
Also you could do a research about particular libraries that interest you. For example for lodash with adjustments you can do:
import get from "lodash/get"
and this will result loading only this module and ultimately smaller bundle size. Same solutions exist for momentjs, etc and many other libraries that are probably big and you end up not using the whole thing.
You could tag this question with webpack to get a more educated and informed answer
I'm trying to figure some things related to ES6 modules. How to use namespaces together with angular and typescript.
Assume the following code represents an angular directive. Does anyone know what the module keyword mean and how can you access MyClass in other file.
// file1.ts
module NSpace.Space {
export class MyClass {
constructor() { ... }
...
}
}
I have tried accessing on another file using and re-exporting, however
// file2.ts
import {MyClass} from 'file1';
export {MyClass}
I get this error: error TS2306: File 'file.ts' is not a module
My questions are:
why do I get this?
what is this module keyword?
do we create ES6 modules only based on the directory structure or can
we actually use this notation? module Space.Space1.Space2 ...
From what I've read and experienced so far it seems that ES6 modules are defined based on file structure, that's why I get this error.
I have not written this code, that's why I'm asking. Also it might be useful to mention that I'm using System.JS for importing.
The module keyword in TypeScript caused a bit of confusion, so it is going to be renamed namespace.
Rather than use namespaces, though, you can organise your code by files / file system (which means the actual file location will match the perceived namespace. This is how "exteral modules" (TypeScript) work - and also how ECMAScript 2015 modules work.
So with a quick adjustment, you'll have:
// file1.ts
export class MyClass {
constructor() { ... }
...
}
And then this will work:
import {MyClass} from 'file1';
If you compile targeting ES6, you'll notice that this line of code needs no translation, it matches the standard for module imports. If you target ES5 or lower, TypeScript will transform this statement for you (you can choose the transformation using the --module flag.
I tend to use the UMD compilation option, which means the output will work in web browsers (with RequireJS) or on Node. System JS is actually gaining a lot of traction currently, so you may want to consider that too. Eventually, browsers will simply natively support module loading.
One of the projects I'm collaborating on has four different modules (Foo, Bar, Baz, and Plotting) and I've been tasked with combining them into a package. It is simple enough in Julia to make a new package:
julia> Pkg.generate("MyPackage", "MIT")
I copied my modules into the ~/.julia/v0.3/MyPackage/src/ and added include statements to MyPackage.jl. It looks something like this:
module MyPackage
include("foo.jl")
include("bar.jl")
include("baz.jl")
include("plotting.jl")
end
Each included file contains the corresponding module.
My main problem with this is Plotting takes forever to import and it's not needed very often when we're using the rest of MyPackage. I'd really like to be able to do something like using MyPackage.Foo to just get Foo (and particularly to exclude the Plotting and its slow import time). I've tried a couple different approaches for how I structure things, including having sub-modules explicitly defined inside MyPackage.jl instead of in each file individually, but no matter what I try, I always get the loading lag from Plotting.
Is it possible build a package so you can independently load modules from it? and if so, how?
Note: I'm new to Julia and newer still to building packages. Sorry if any of my semantics are wrong or anything is unclear.
Try Requires.jl:
Requires is a Julia package that will magically make loading packages faster, maybe. It supports specifying glue code in packages which will load automatically when a another package is loaded, so that explicit dependencies (and long load times) can be avoided.
Is it possible build a package so you can independently load modules from it? and if so, how?
Following the advice of this comment has worked for me:
https://discourse.julialang.org/t/multiple-modules-in-single-package/5615/7?u=nhdaly
You can change the top-level package-named Module to simply just expose the other four Modules as follows:
# <julia_home>/MyPackage/src/MyPackage.jl
module MyPackage
push!(LOAD_PATH, #__DIR__) # expose all other modules defined in this directory.
end
Then to import the other modules, say Bar, the user code would do:
# code.jl
using MyPackage; using Foo;
...
But it's worth noting that, then, Foo, Bar, Baz and Plotting are all also treated as top-level modules, so you'll want to make their names unique so they don't conflict with other Packages/Modules. (ie somethig like MyPackageFoo, not Foo.)
Consider I have large library package with sophisticated tree of private or package modules — let's call it funnylib. It's not desirable for enduser to touch internal modules directly (like funnylib.foo, funnylib.bar etc), so I want to provide external interface instead — like this:
funnylib.d:
public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;
to be just imported like import funnylib by enduser. The problem is that D disallows having funnylib.d and funnylib/ at the same time.
Is there something like "default package module" in D, like there is __init__.py in Python? If no, what is right way to do design described above?
Update1: I thought about moving iternal modules to package like funnylib_private, so funnylib will import fine, but this will have cost of protection lowering (strongly undesirable), as funnylib will no longer access package protected symbols, and will result in unpleasant file layout.
You cannot have a module and a package with the same name. So, for instance, Phobos couldn't have a std/algorithm.d and a std/algorithm/sorting.d. std/algorithm.d and std/algorithm would conflict. The typical thing to do is what ratchet freak describes and use a module named all which publicly imports all of the modules within that package. But if you want to hide the fact that you're using sub-modules at all, then you could simply do something like
funnylib.d
_funnylib/foo.d
_funnylib/bar.d
_funnylib/baz.d
and not document _funnylib anywhere, but that doesn't work very well with ddoc, because it's going to generate the documentation for each of the _funnylib modules, and the most that it'll generate for funnylib.d is the module documentation, because it doesn't have any symbols to document. The module system is not designed with the idea that you're going to be hiding modules like you're trying to do.
Now, there is currently a proposal under discussion for making it possible to cleanly split up a module into a package when it gets too large (e.g. so that when you split up std.algorithm into std.algorithm.search, std.algorithm.sorting, etc. code which explicitly uses std.algorithm.countUntil won't break even though it's now std.algorithm.search.countUntil). And once that's sorted out, you could use that, but the documentation would still be done for each sub-module, not for your uber-module. It's really meant as a means of transitioning code, not trying to hide the fact that you're splitting up your modules. It's basically just the equivalent of using an all module but with some semantic sugar to avoid breaking code in the case where the package used to be a single module.
create a simple all module with the public imports that is documented to import the library
module funnylib.all;
public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;