Rather than having a single bundle for my rollup react app in development, I split it into two bundles. One for the dependencies and one for the app itself.
This way the watch mode stays fast (as it now doesn't has to parse the dependencies continously) and I don't have to write (or use third party) es module wrappers for libraries such as React.
While the code is bundled without any errors, I run into TypeError: React is undefined while running it. When I check the network panel in developer tools I do see the dependency bundles getting downloaded.
Here is how I am using rollup with its API.
You can see the rest of the relevant code here.
Can anyone point out what am I doing wrong? Any help appreciated!
This is a bug in the latest #rollup/plugin-commonjs version (14.0.0). It was fixed with the merge of this PR, but this hasn't been released to NPM yet. I went and built the latest version from GitHub, and used it with the repo in question, and React is now working.
So for now the solution is to use the latest source on GH until the next version is published.
Related
I have a project that uses Webpack for bundling and ESLint for code quality. I just upgraded from Webpack 4.35.2 to version 5.64.2, which seems to have broken the ESLint test.
The project has a third-party dependency that itself uses Webpack v3 and relies on NamedModulesPlugin which existed in that version. This was still present in v4 but removed from v5 and I now get the error TypeError: webpack.NamedModulesPlugin is not a constructor when running the ESLint test.
Obviously, the dependency is not using version 3 as specified in its own package.json but rather the version of the main project. This is clearly very wrong and I don't understand how this is even meant to work.
I'm using eslint-plugin-import and eslint-import-resolver-webpack to resolve the import statements in my source files and I guess that simply doesn't handle incompatible versions of the same package used across the dependency tree? Everything works fine when running and building the project.
I'm at a loss as to how I can resolve this or work around it so if anyone has any pointers I would greatly appreciate it!
I apologize, my lack of knowledge of how to build modern Javascript apps is showing.
We have a Capacitor app that uses plain Javascript, without any build tools. This works fine. We're trying to add Microsoft Code Push support, via https://github.com/mapiacompany/capacitor-codepush, and we're running into a problem with how to integrate it into our app.
For Capacitor and its plugins, we use tags to include the plugin.js files from the various node_modules/.../dist directories.
If we do this with node_modules/capacitor-codepush/dist/plugin.js, we get an error about missing acquisitionSdk. Including node_modules/code-push/script/acquisition-sdk.js doesn't help.
Ok, so maybe there are a bunch of dependencies? We tried using rollup to see if we could get that to work, but cannot. Using this simple input file:
import { codePush } from 'capacitor-codepush';
console.log("hello");
we get [!] Error: Invalid value "iife" for option "output.format" - UMD and IIFE output formats are not supported for code-splitting builds.
Any help would be appreciated.
The only way I was able to get it working was to switch to using webpack. For reasons I don't understand, my initial attempts using rollup did not work. webpack was the key.
You should run the dist version of your app. Meaning, you should use a bundler like webpack. Unbundled (pure) code can't use these features.
I have been looking for a way to mostly share some code between projects specifically for SPFX and fluent ui. We found 3 main ways to do that.
1.
Creating a component library is the way that seemed least complicated cause it uses the same infrastructure and do all building without the need to configure it.
But this adds some issues, we need to built and manually link the solution locally to make it work, this will also work if we put in a repo. so this is mitigated.
The second is that implicitly this will also require the fluent ui and react. Plus having to place it inside a SPFX component library project.
2.
I saw some promise using paths in ts and this works fine while using the ts compiler. It will go to the folder that your proj is referring and build it at calling time. which is great. But it did not work in SPFX.
3.
Another way was to have a post install to sync the folders which seems easy enough but I wonder how practical this is plus how people are doing it, if they are, how.
All I wanted to figure out now is a way to take my component code and share as if they were in a folder of my src or a simple extension of the code. No need to have extra dependencies or build steps, just the code that can be used as a ts/tsx file. ex:
shared lib:
//assuming I have react and fluentui already installed for the project.
import button from 'fluentui';
export const fancyCustomButtom = (props) => {
return (<Button text="Standard" />);
};
src project folder:
import {fancyCustomButtom} from 'shared-lib'
It is fine if it needs to build the files before we can use it but can we do it at build time or when the package is installed? also wouldn't it increase my bundle size by making both module dependent on things already available (react, fluentui)?
Given the way Microsoft have architected the loading of bundles in SharePoint and Teams - I believe an SPFX component library is the best way to share code between different solutions, particularly if you are looking to minimise bundle size...
Imagine you have a library for something re-usable: a form, a set of standard branded components - something of that nature. You could put your shared code in repos and add references to it - either by publishing your own repo publicly or using the npm install git+https://yourUrl syntax; but what effectively happens there is that your code is pulled down in to node_modules for each project, and any referenced module code is included in your bundles. If you have two, three, four or more webparts on the same page - using those same libraries, you're multiplying how many times that code is included on the page.
If you follow Microsoft's guide on setting up a component library project however, your npm link commands allow your types to be recognised in consuming projects without needing to actually include the bundled distribution code. You can deploy your library code once to the App Catalog, and if it's referenced in other solutions -- it's loaded on pages as needed: once.
I have found the development experience to be quite flaky at times, but it does work. When I run gulp clean on my library code, or come back to it after some time, I sometimes find that I need to run npm link and npm link my-project-name again as per the instructions in the above tutorial. Whenever you run gulp build on your library, you should also rebuild the project that consumes the library, either by using gulp build / bundle or by saving a file (if you're running gulp serve). This process works well for developing, and once it comes time to deploy, all you need to do is add a named reference to your library inside package.json and then deploy both .sppkg files to your App Catalog.
In terms of your last question re: bundle size - react is not actually included in the dependencies for an SPFX library project, but you will find it's available to use. When you build your library, if you take a look in the generated javascript in your dist folder, you will see it's listed as one of the dependencies for the webpacked content along with react-dom and ControlStrings. It's on line 1.
office-ui-fabric-react is included as a devDependency thanks to the #microsoft/sp-webpart-workbench package that gets scaffolded with all SPFX projects - and if you check your library's dist javascript, you will see that included components are being webpacked and included in your bundle. I'm not entirely sure if when you pull this code in to your consuming project, whether webpack then tree-shakes to de-duplicate and ensures only necessary code is included: I don't know. Someone else may be able to illuminate us there or provide a more accurate explanation of what's going on... I will update this response if anyone comments to let me know.
And finally, this is more of a personal way of working, but it may be worth consideration:
When developing a library, I sometimes reference it in other projects via a local npm install ../filepath command. This ensures that when I install the library as described, the consuming project installs any necessary dependencies. I'm able to tweak both projects if I need o. When it comes time to deploy, I commit my changes to both projects, deploy my library code to the App Catalog, and then npm uninstall the library from the consuming project and add a reference as described in the above tutorial. When I deploy projects that use my library, they just work.
I recently developed a library that uses pnpjs, in particular the #pnp/sp library that is used to talk to SharePoint. If you look at the Getting Started guide for that library, they expect you to pass a reference to your Application Customizer or Web Part context during setup, or explicitly set things up using a base URL and so forth - and of course, a library doesn't really have a page context of any sort - the whole point of this code is that it's reusable. So that poses a challenge. My solution was to do the setup in the consuming web part(s) and ensure that they pass a reference to the sp object (which is of type SPRest) to any code or components that exist in my library. My library has peerDependencies on those pnp libraries so that the code isn't duplicated in consuming projects. Sometimes you have to think about what your library needs to include in its bundle and what you expect consuming solutions to already have, and maybe find ways to ensure things aren't included that aren't needed.
For example, in the scenario you talk about, you may want to ensure fluentui or office-ui-fabric-react are only devDependencies or peerDependencies for your library. As long as your library and the project(s) consuming your library both use the right version(s) you shouldn't have any trouble, and you can document any pre-requisites with your library documentation. You can check which versions of these libraries are installed per the SPFX version you are currently using ie. SPFX v1.11 or v1.12 etc. Just run npm ls <packagename> to get a breakdown, or check your package.json file.
As soon as I add a tsconfig.json file to my Visual Studio 2015 web solution I get the above error.
Also this stops the compiler from re-generating js files even when I set "compileOnSave": true.
When I double click the error it takes me into the Microsoft.Typescript.Targets file which contains a lot of issues such as Unknown Item Group "TypeScriptCompile". In the error list these appear as warnings but they are there whether I have a tsconfig.json file or not.
Is there any way of solving it or getting more information on what the problem is?
Install these 2 NuGet packages:
Microsoft.TypeScript.MSBuild and Microsoft.TypeScript.Compiler
It updates your project with MSBuild task definition and TS compiler and solves the compilation issue
For me installing TypeScript for Visual Studio fixed it, although TypeScript was already installed globally on my machine via npm
I am using a .NET Core 1.0 project and ran into the same situation of getting a tsc.exe return code of 1. My problem was an invalid tsconfig.json. However, msbuild does not provide those details.
The easiest way to find out is to enable detailed output in Visual Studio -> Tools -> Options -> Projects and Solutions -> Build and Run -> MSBuild project build output verbosity. Change this to Detailed. After compiling, find tsc.exe in the output window to see the actual error tsc was throwing.
I had this problem as well after using some standard Angular / Typescript tutorials. The solution was as simple as to update typescript in Visual Studio.
For some reason the default is now 1.8.4. and it does not allow you to automatically update it from Visual Studio Extensions and does not say it is out of date. You just download it from here and install newest version yourself. Download link may change in the future of course.
P.S. I think the problem was caused by the fact that some options that did not exist in older compiler were used.
This worked for TeamCity build server with Visual Studio 2015 when I had upgraded a project from Typescript 1.8 to 2.3
Install package Microsoft.TypeScript.MSBuild
Update *.csproj as follows
Upgrade TypeScriptToolsVersion to 2.3 (in this case)
Remove two lines of Import Project that referred to
Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets
Note
Removing the import elements is important as they are referring to TypeScript installed in the %PROGRAMFILES(X86)% folder.
Installing the package adds import elements that reference the packages folder - making your build more portable
I had same issue and what happened in my case is that the file .ts was in the project but it was not on file system. Something like this . So removed the file from project and everything started to work again.
Move all files within C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Typescript into some new folder (e.g. backup), then try again. This will cause MSBuild to select tsc.exe from within the appropriately versioned folder instead of using the one in the C:\Program Files (x86)\Microsoft SDKs\TypeScript.
Installing Microsoft.Typescript.MsBuild fixed the issue for me, but only if I installed the penultimate version. The current (stable) version is 2.0.6, and after I installed it, the issue persisted. When I reverted to 1.8.11, the issue went away.
I had the same issue. Fixed it by removing the following from the project file
<TypeScriptToolsVersion>2.0</TypeScriptToolsVersion>
Double clicking on one of the .ts files inside of visual studio worked for me. It then came up with a dialog box asking if I wanted to update the project to the latest version of TS. After that the project built fine and the compile error was gone.
There is need to Re-Install/Upgrade, Typescript in your system.
As i was facing same issue and after installing Typescript again got resolved the error, as tsc.exe was missing in (C:\Program Files (x86)\Microsoft SDKs\TypeScript\2.1).
We are using npm and angular-cli outside VS to transpile our typescript. I ran into the problem described above on the only dev box that had the Web Essentials extension loaded. After trying installing, and then uninstalling the MS nugets and TypeScript extension described above to no avail, uninstalling Web Essentials finally did the trick.
I was facing same issue, and the reason was, 2 developers were working on same project so when he added new .ts files into project and some angular controllers. The project was rebuilding and running as expected however when another developer tried to take latest source code on his machine and on rebuilding he was getting same error "tsc.exe" exited with code 1.
So reason was the files created/added in source control was not showing added on
developer 2 solution. Please try to check if all the .ts, .js files are up to date on both developers solution.
I had the same issue on a solution using AngularJS but without the compiler (below 2.x so not needed). I simply removed the index.d.ts from script folder and it was ok (no NuGet packages necessary)
If youre are facing this problem when updating from bootstrap 3 to 4 just delete .ts file created inside the Scripts Folder then build again.
I started my React Native project with version 0.12.0 and Baobab. Everything worked great until React Native 0.14.2. In any version since then, the transform in the packager stops at 98% and the JS load fails.
I have used some of the advice in this github issue to determine that it's transforming a file in Baobab (baobab/dist/update.js or baobab/dist/watcher.js in different runs).
I have confirmed that Baobab is the issue by creating a clean React Native 0.16.0 install and only putting Baobab in it (with the required require)
At this stage, I'm not sure whether I should raise an issue with React Native or with Baobab, so I'm looking for advice on how to get some sort of error message that I can use to debug the issue and work out what's going wrong.
Ok. Worked this out myself:
By adding debug=babel to the environment the packager is running in, I got a huge amount of output and hidden in there was an error that .babelrc in the baobab package had an optional entry and the React Native packager doesn't understand optional. I deleted the .babelrc from the baobab package and everything works.