Goal:
I'm trying to build a UI-Kit that can be consumed by web applications and react native applications. I have a specific need to be able to do this without react-native-web.
My Solution:
Create a UI Kit that has a shared interface layer. I have a project that exports two nested folders. #abc/ui-kit/web and #abc/ui-kit/native
My Problem:
When I import the UI Kit package, Typescript complains about a missing module definition.
import { Button } from '#abc/ui-kit';
import { Button } from '#abc/ui-kit/web';
Cannot find module '#abc/ui-kit' or its corresponding type
declarations
Cannot find module '#abc/ui-kit/web' or its corresponding
type declarations
My package.json for the UI-Kit has the following exports:
"exports": {
"web": {
"types": "./dist/web/index.d.ts",
"default": "./dist/web/index.ts"
},
"native": {
"types": "./dist/native/index.d.ts",
"default": "./dist/native/index.ts"
}
}
You can find the code here on Github. Easy to recreate, I tried keeping it minimal. Is what I'm trying to do possible? Or do I need to completely restructure my application?
https://github.com/Spidy88/multi-platform-example/tree/master
Note: If you look under the dev branch, I have a v1 UI Kit and App which shows how a regular library and consuming app work. No issues with it. The v2 UI Kit and App are my next iteration where I try and turn a single package into a multiple platform package (which essentially is two packages in one using package.json exports). This v2 version is what doesn't seem to work
Subpaths must start with ./ (answered by a colleague) Subpath Docs
"exports": {
"./web": {
"types": "./dist/web/index.d.ts",
"default": "./dist/web/index.ts"
},
"./native": {
"types": "./dist/native/index.d.ts",
"default": "./dist/native/index.ts"
}
}
Related
We have been asked to build some spfx extensions for SharePoint Online. Using yeoman some essential files are being generated such as :
elements.xml,
ClientSideInstance.xml (for tenant wide deployment in SharePoint,
some .json files in the config folder for debuggin/packaging the solution
the files inside the src/extensions folder with the manifest.json and the .ts file.
files outside src such as gulpfile.js, package.json, .yo-rc.json and tsconfig.json
The structure resembles the following:
When I packaged the solution for uploading it to sharepoint, I decided to make many packages from the same solution, using a suffix such spo-extension-test.sspkg, spo-extension-dev.sspkg to use in different sites (for different environments) but in the same tenant.
In the apps catalog site however, I received the following warning,
The product Id, is in the package-solution.json,
{
"$schema": "https://developer.microsoft.com/json-schemas/spfx-build/package-solution.schema.json",
"solution": {
"name": "spfx-extension",
"id": "2475dj2f-733b-41e5-8k39-d78ba3ce2fme",
"version": "1.0.0.0",
"includeClientSideAssets": true,
.... //more settings
and in the .yo-rc.json file as library Id.
{
"#microsoft/generator-sharepoint": {
"plusBeta": false,
"isCreatingSolution": true,
"environment": "spo",
"version": "1.13.1",
"libraryName": "spfx-extension",
"libraryId": "2475dj2f-733b-41e5-8k39-d78ba3ce2fme",
"packageManager": "npm",
"isDomainIsolated": false,
"componentType": "extension",
"extensionType": "ApplicationCustomizer"
}
}
As I understand, this guid is also automatically generated through yeoman but I was wondering if for different environment packages can be changed manually to bypass this warning. What are the caveats of something like this? Is it considered bad practice?
And in the end, if it is, how can I create different extension packages with the suffix to match the environments in my tenant?
I have been trying to build my gatsby (react) site recently using an external package.
The link to this package is "https://github.com/transitive-bullshit/react-particle-animation".
As I only have the option to change the props from the components detail, I cannot read/write the package file where it all gets together in the end as it is not included in the public folder of 'gatsby-build'.
What I have tried:
Editing the package file locally, which worked only on my machine but when I push it to netlify, which just receives the public folder and the corresponding package.json files and not the 'node-modules folder', I cannot make netlify read the file that I myself changed, as it requests it directly from the github page.
As a solution I found from a comment to this question, we can use the "Patch-Package" to save our fixes to the node module and then use it wherever we want.
This actually worked for me!
To explain how I fixed it: (As most of it is already written in the "Patch Package DOCS), so mentioning the main points:
I first made changes to my local package files that were giving the error.(For me they were in my node_modules folder)
Then I used the Patch Package Documentation to guide my self through the rest.
It worked after I pushed my changes to github such that now, Patch Package always gives me my edited version of the node_module.
When dealing with third-party modules that use window in Gatsby you need to add a null loader to its own webpack configuration to avoid the transpilation during the SSR (Server-Side Rendering). This is because gatsby develop occurs in the browser (where there is a window) while gatsby build occurs in the Node server where obviously there isn't a window or other global objects (because they are not even defined yet).
exports.onCreateWebpackConfig = ({ stage, loaders, actions }) => {
if (stage === "build-html") {
actions.setWebpackConfig({
module: {
rules: [
{
test: /react-particle-animation/,
use: loaders.null(),
},
],
},
})
}
}
Keep in mind that the test value is a regular expression that will match a folder under node_modules so, ensure that the /react-particle-animation/ is the right name.
Using a patch-package may work but keep in mind that you are adding an extra package, another bundled file that could potentially affect the performance of the site. The proposed snippet is a built-in solution that is fired when you build your application.
I am following the directions in the documentation https://www.gatsbyjs.org/docs/eslint/, and would like to overwite one of the rules, but not affect the others, what I did is create an .eslintrc.js file.
This is the content of the file
module.exports = {
globals: {
__PATH_PREFIX__: true,
},
extends: `react-app`,
"rules": {
'jsx-a11y/no-static-element-interactions': [
'error',
{
handlers: [
'onClick',
'onMouseDown',
'onMouseUp',
'onKeyPress',
'onKeyDown',
'onKeyUp',
],
},
],
}
}
but the rest of the rules are now ignored, like it was not an extension
While the answer above is correct, it is a bit incomplete. The thing is eslint can be integrated both in builds and editors.
When you start using a custom .eslintrc.js you will lose the integration on build and output in the terminal based on those rule. That's because the built-in eslint-loader is disabled when you use a custom file. It actually says so on the documentation page but it is a bit unclear.
To get that back, you will need to integrate it in the webpack build. The easiest way is using the plugin mentioned on the doc page: gatsby-plugin-eslint.
I filed an issue to make custom integrations easier.
From the Gatsby docs you linked to:
When you include a custom .eslintrc file, Gatsby gives you full control over the ESLint configuration. This means that it will override the built-in eslint-loader and you need to enable any and all rules yourself. One way to do this is to use the Community plugin gatsby-eslint-plugin. This also means that the default ESLint config Gatsby ships with will be entirely overwritten. If you would still like to take advantage of those rules, you’ll need to copy them to your local file.
So it looks like as soon as your create a .eslintrc.js file, you need to build your rules up from the bottom again. It overwrites, it doesn't extend.
I'm using Visual studio code to develop nodeJS apps and already have an eslint configuration to lint undeclared variables.
But in recent VSCode versions, some undeclared variable are not linted anymore. like event, name, crypto, ...
When reaching the variable definition, it is actually declared in the file Microsoft VS Code Insiders\resources\app\extensions\node_modules\typescript\lib\lib.dom.d.ts
I can't see any reason why those variables should be declared globally for nodeJS apps. How can I disable the global definition of thoses variables?
From the docs for tsconfig.json compilerOptions.lib:
TypeScript includes a default set of type definitions for built-in JS APIs (like Math), as well as type definitions for things found in browser environments (like document).
You can exclude dom suggestions by setting "lib": ["es6"] (or whichever ECMA Script standard API version you want to be able to use) in a jsconfig.json:
{
"compilerOptions": {
"target": "ES6",
"lib": ["es6"]
},
"exclude": [
"node_modules",
"**/node_modules/*"
]
}
I am a newbie in the asp.net net core world and I am struggling to adding a simple ref .
I get an error
Steps
1) Created an "Asp.net Core Web Application(Net Framework) RC2"
2) Added a Class Library (.Net core) called "ClassLibrary1")
3)Within the web app.Project.json i added a reference to the classlibrary1 like this
"dependencies": {
"ClassLibrary1": "1.0.0-*", etc...
4) Get error
Severity Code Description Project File Line Suppression State
Error
NU1001 The dependency ClassLibrary1 could not be resolved.
I understand why microsoft is doing this as they want to be lean and modular,however
there should be an option that would add the reference for you like in the classic library.It's a step back in my view.
Is this a bug or its me?
thanks for any reply
Change your project.json in your class library to .netstandard1.4 (or lower).
Your web application is stating .NET Framework 4.6.1, but netstandard 1.5 can only target 4.6.2+ (related to .NET Framework that is).
https://github.com/dotnet/standard/blob/master/docs/versions.md
{
"version": "1.0.0-*",
"dependencies": {
"NETStandard.Library": "1.5.0-rc2-24027"
},
"frameworks": {
"netstandard1.4": {
"imports": "dnxcore50"
}
}
}
I ran into the same Problem. I had to manually run "Restore Packages" and the error was gone!