Deploying uniswap v3 gets compiler errors - solidity

I am playing around with uniswap V3 on testnet and I am wondering, is it necessary to import all files and compile them to deploy the required contracts? I am getting a lot of compiler errors even though I specified them all in my hardhat config.
Config:
solidity: {
compilers: [
{
version: '0.5.16',
settings: {
optimizer: {
enabled: true,
runs: 200,
},
},
},
{
version: '0.8.0',
settings: {
optimizer: {
enabled: true,
runs: 200,
},
},
},
{
version: '0.8.1',
settings: {
optimizer: {
enabled: true,
runs: 200,
},
},
},
{
version: '0.6.6',
settings: {
optimizer: {
enabled: true,
runs: 200,
},
},
},
{
version: '0.7.6',
settings: {
optimizer: {
enabled: true,
runs: 200,
},
},
},
],
},
Error:
Error HH606: The project cannot be compiled, see reasons below.
These files import other files that use a different and incompatible version of Solidity:
* contracts/periphery/interfaces/external/IWETH9.sol (=0.7.6) imports #openzeppelin/contracts/token/ERC20/IERC20.sol (^0.8.0)
* contracts/periphery/interfaces/IERC20Metadata.sol (^0.7.0) imports #openzeppelin/contracts/token/ERC20/IERC20.sol (^0.8.0)
* contracts/Token.sol (=0.5.16) imports #openzeppelin/contracts/token/ERC20/ERC20.sol (^0.8.0)
* contracts/periphery/base/ERC721Permit.sol (=0.7.6) imports #openzeppelin/contracts/token/ERC721/ERC721.sol (^0.8.0) and #openzeppelin/contracts/utils/Address.sol (^0.8.1)
These files depend on other files that use a different and incompatible version of Solidity:
* contracts/periphery/SwapRouter.sol (=0.7.6) depends on #openzeppelin/contracts/token/ERC20/IERC20.sol (^0.8.0), #openzeppelin/contracts/token/ERC20/IERC20.sol (^0.8.0) and 19 other files. Use --verbose to see the full list.
* contracts/periphery/V3Migrator.sol (=0.7.6) depends on #openzeppelin/contracts/token/ERC721/extensions/IERC721Metadata.sol (^0.8.0), #openzeppelin/contracts/token/ERC721/extensions/IERC721Enumerable.sol (^0.8.0) and 22 other files. Use --verbose to see the full list.
* contracts/periphery/NonfungiblePositionManager.sol (=0.7.6) depends on #openzeppelin/contracts/token/ERC721/extensions/IERC721Metadata.sol (^0.8.0), #openzeppelin/contracts/token/ERC721/extensions/IERC721Enumerable.sol (^0.8.0) and 38 other files. Use --verbose to see the full list.
* contracts/periphery/NonfungibleTokenPositionDescriptor.sol (=0.7.6) depends on #openzeppelin/contracts/token/ERC721/extensions/IERC721Metadata.sol (^0.8.0), #openzeppelin/contracts/token/ERC721/extensions/IERC721Enumerable.sol (^0.8.0) and 13 other files. Use --verbose to see the full list.
* contracts/periphery/libraries/PositionValue.sol (>=0.6.8 <0.8.0) depends on #openzeppelin/contracts/token/ERC721/extensions/IERC721Metadata.sol (^0.8.0), #openzeppelin/contracts/token/ERC721/extensions/IERC721Enumerable.sol (^0.8.0) and 6 other files. Use --verbose to see the full list.
* contracts/periphery/examples/PairFlash.sol (=0.7.6) depends on #openzeppelin/contracts/token/ERC20/IERC20.sol (^0.8.0), #openzeppelin/contracts/token/ERC20/IERC20.sol (^0.8.0) and 2 other files. Use --verbose to see the full list.
* contracts/periphery/base/LiquidityManagement.sol (=0.7.6) depends on #openzeppelin/contracts/token/ERC20/IERC20.sol (^0.8.0), #openzeppelin/contracts/token/ERC20/IERC20.sol (^0.8.0) and 1 other file. Use --verbose to see the full list.
These files and its dependencies cannot be compiled with your config. This can happen because they have incompatible Solidity pragmas, or don't match any of your configured Solidity compilers.
* contracts/periphery/libraries/NFTDescriptor.sol
* contracts/periphery/base/PeripheryPaymentsWithFee.sol
* contracts/periphery/base/PeripheryPayments.sol
To learn more, run the command again with --verbose
Read about compiler configuration at https://hardhat.org/config
When deploying uniswapV2 I did not run into these same issues while it was necessary to import a good chunk of files aswell. Is that because solidity 0.5 and 0.6 are more compatible?

You have contracts with different solidity compiler versions and specified a bunch in your config.
However, just one compiler will be selected for compilation of a contract and its dependencies.
Hence, when you specify pragma ^0.7.6 it means that you need at least compiler version 0.7.6, but the selected compiler must be <0.8.0). Yet imported contracts are dependant on ^0.8.0 -> Error
One fix is to install openzeppelin at this version 0.7.0:
npm install #openzeppelin/contracts#3.4.2-solc-0.7
Alternatively you could updated your uniswap contracts to 0.8.0
https://github.com/Uniswap/v3-periphery/tree/0.8/contracts
https://github.com/Uniswap/v3-core/tree/0.8/contracts

Related

TronBox compile issue

I've installed the latest tronbox (2.7.5) using npm
Created a new project using command tronbox init
In file tronbox.js I've updated the compiler version to 0.4.25 (see the file below).
When compiling using the command tronbox compile --compile-all --reset I'm getting:
Windows error:
And then the following message in my terminal:
Error: Error parsing C:/dev/temp/contracts/Migrations.sol: Command failed: tronbox --download-compiler 0.4.25
at checkExecSyncError (child_process.js:575:11)
at execSync (child_process.js:612:13)
at getWrapper (C:\Users\***\AppData\Roaming\npm\node_modules\tronbox\build\components\TronSolc.js:1:1717)
at Object.parseImports (C:\Users\***\AppData\Roaming\npm\node_modules\tronbox\build\components\Compile\parser.js:1:2345)
at C:\Users\***\AppData\Roaming\npm\node_modules\tronbox\build\components\Compile\profiler.js:1:4981
at C:\Users\***\AppData\Roaming\npm\node_modules\tronbox\build\components\Resolver\index.js:1:1727
at C:\Users\***\AppData\Roaming\npm\node_modules\tronbox\node_modules\async\internal\onlyOnce.js:12:16
at next (C:\Users\***\AppData\Roaming\npm\node_modules\tronbox\node_modules\async\whilst.js:68:18)
at C:\Users\***\AppData\Roaming\npm\node_modules\tronbox\build\components\Resolver\index.js:1:1495
at C:\Users\***\AppData\Roaming\npm\node_modules\tronbox\build\components\Resolver\fs.js:1:1685
I added this line to the top of my tronbox.js file:
console.log('Running tronbox compile');
and noticed that once compiling the output is written twice on my screen:
I'm not sure it relates but for some reason, it runs twice.
Any idea? Is this a tronbox issue?
const port = process.env.HOST_PORT || 9090
module.exports = {
networks: {
mainnet: {
// Don't put your private key here:
privateKey: process.env.PRIVATE_KEY_MAINNET,
/*
Create a .env file (it must be gitignored) containing something like
export PRIVATE_KEY_MAINNET=4E7FECCB71207B867C495B51A9758B104B1D4422088A87F4978BE64636656243
Then, run the migration with:
source .env && tronbox migrate --network mainnet
*/
userFeePercentage: 100,
feeLimit: 1e8,
fullHost: 'https://api.trongrid.io',
network_id: '1'
},
shasta: {
privateKey: process.env.PRIVATE_KEY_SHASTA,
userFeePercentage: 50,
feeLimit: 1e8,
fullHost: 'https://api.shasta.trongrid.io',
network_id: '2'
},
nile: {
privateKey: process.env.PRIVATE_KEY_NILE,
fullNode: 'https://httpapi.nileex.io/wallet',
solidityNode: 'https://httpapi.nileex.io/walletsolidity',
eventServer: 'https://eventtest.nileex.io',
network_id: '3'
},
development: {
// For trontools/quickstart docker image
privateKey: 'da146374a75310b9666e834ee4ad0866d6f4035967bfc76217c5a495fff9f0d0',
userFeePercentage: 0,
feeLimit: 1e8,
fullHost: 'http://127.0.0.1:' + port,
network_id: '9'
},
compilers: {
solc: {
version: '0.4.25'
}
}
}
}
This seems like a regression bug in tronbox 2.7.4 and 2.7.5 since when I use tronbox 2.5.2 everything works smoothly.

The implementation option must be passed to the Sass task

Running grunt - I get this error message:
Running "sass:all" (sass) task
Fatal error: The implementation option must be passed to the Sass task
I've tried re-installing grunt, node, npm, dependencies - but I always come back to this error I can't get past.
Should I post my Gruntfile.js? Frankly, this was set up by a third-party and we don't use it often - I'm thinking maybe we should start from the ground up because it is from about 4 years ago originally... but wondering if anyone has seen this error before and knows of a fix/workaround.
With the update to grunt-sass 3, you have to choose whether you want to use node-sass or dart-sass to compile
For node-sass you need to install the module with:
$ npm install --save-dev node-sass
In you gruntfile, you than need to add node-sass as requirement and add the define constant as implementation option:
const sass = require('node-sass');
require('load-grunt-tasks')(grunt);
grunt.initConfig({
sass: {
options: {
implementation: sass,
sourceMap: true
},
dist: {
files: {
'main.css': 'main.scss'
}
}
}
});
See also official page for more details: https://www.npmjs.com/package/grunt-sass
use this
**const sass = require("node-sass");**
**grunt.initConfig({
sass: {
options: {
implementation: sass,
sourceMap: true,
},
dist: {
files: {
"css/styles.css": "css/styles.css",
},
},
},
});
This will help you solve the problem
UPDATE: Only works for grunt-sass 2.x
I had this problem when upgrading from grunt-sass 1.x to 2.x. This solved it for me:
Add implementation: 'sass' to your sass.options object in Gruntfile.js like so:
options: {
implementation: 'sass',
outputStyle: 'expanded',
sourceMap: true,
quiet: true // stop depreciation errors
},

Field 'browser' doesn't contain a valid alias configuration

I've started using webpack2 (to be precise, v2.3.2) and after re-creating my config I keep running into an issue I can't seem to solve I get (sorry in advance for ugly dump):
ERROR in ./src/main.js
Module not found: Error: Can't resolve 'components/DoISuportIt' in '[absolute path to my repo]/src'
resolve 'components/DoISuportIt' in '[absolute path to my repo]/src'
Parsed request is a module
using description file: [absolute path to my repo]/package.json (relative path: ./src)
Field 'browser' doesn't contain a valid alias configuration
aliased with mapping 'components': '[absolute path to my repo]/src/components' to '[absolute path to my repo]/src/components/DoISuportIt'
using description file: [absolute path to my repo]/package.json (relative path: ./src)
Field 'browser' doesn't contain a valid alias configuration
after using description file: [absolute path to my repo]/package.json (relative path: ./src)
using description file: [absolute path to my repo]/package.json (relative path: ./src/components/DoISuportIt)
as directory
[absolute path to my repo]/src/components/DoISuportIt doesn't exist
no extension
Field 'browser' doesn't contain a valid alias configuration
[absolute path to my repo]/src/components/DoISuportIt doesn't exist
.js
Field 'browser' doesn't contain a valid alias configuration
[absolute path to my repo]/src/components/DoISuportIt.js doesn't exist
.jsx
Field 'browser' doesn't contain a valid alias configuration
[absolute path to my repo]/src/components/DoISuportIt.jsx doesn't exist
[[absolute path to my repo]/src/components/DoISuportIt]
[[absolute path to my repo]/src/components/DoISuportIt]
[[absolute path to my repo]/src/components/DoISuportIt.js]
[[absolute path to my repo]/src/components/DoISuportIt.jsx]
package.json
{
"version": "1.0.0",
"main": "./src/main.js",
"scripts": {
"build": "webpack --progress --display-error-details"
},
"devDependencies": {
...
},
"dependencies": {
...
}
}
In terms of the browser field it's complaining about, the documentation I've been able to find on this is: package-browser-field-spec. There is also webpack documentation for it, but it seems to have it turned on by default: aliasFields: ["browser"]. I tried adding a browser field to my package.json but that didn't seem to do any good.
webpack.config.js
import path from 'path';
const source = path.resolve(__dirname, 'src');
export default {
context: __dirname,
entry: './src/main.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].js',
},
resolve: {
alias: {
components: path.resolve(__dirname, 'src/components'),
},
extensions: ['.js', '.jsx'],
},
module: {
rules: [
{
test: /\.(js|jsx)$/,
include: source,
use: {
loader: 'babel-loader',
query: {
cacheDirectory: true,
},
},
},
{
test: /\.css$/,
include: source,
use: [
{ loader: 'style-loader' },
{
loader: 'css-loader',
query: {
importLoader: 1,
localIdentName: '[path]___[name]__[local]___[hash:base64:5]',
modules: true,
},
},
],
},
],
},
};
src/main.js
import DoISuportIt from 'components/DoISuportIt';
src/components/DoISuportIt/index.jsx
export default function() { ... }
For completeness, .babelrc
{
"presets": [
"latest",
"react"
],
"plugins": [
"react-css-modules"
],
"env": {
"production": {
"compact": true,
"comments": false,
"minified": true
}
},
"sourceMaps": true
}
What am I doing wrong/missing?
Turned out to be an issue with Webpack just not resolving an import - talk about horrible horrible error messages :(
// I Had to change:
import DoISuportIt from 'components/DoISuportIt';
// to (notice the missing `./`)
import DoISuportIt from './components/DoISuportIt';
Just for record, because I had similiar problem, and maybe this answer will help someone: in my case I was using library which was using .js files and I didn't had such extension in webpack resolve extensions. Adding proper extension fixed problem:
module.exports = {
(...)
resolve: {
extensions: ['.ts', '.js'],
}
}
I'm building a React server-side renderer and found this can also occur when building a separate server config from scratch. If you're seeing this error, try the following:
Make sure your entry value is properly pathed relative to your context value. Mine was missing the preceeding ./ before the entry file name.
Make sure you have your resolve value included. Your imports on anything in node_modules will default to looking in your context folder, otherwise.
Example:
const serverConfig = {
name: 'server',
context: path.join(__dirname, 'src'),
entry: {serverEntry: ['./server-entry.js']},
output: {
path: path.join(__dirname, 'public'),
filename: 'server.js',
publicPath: 'public/',
libraryTarget: 'commonjs2'
},
module: {
rules: [/*...*/]
},
resolveLoader: {
modules: [
path.join(__dirname, 'node_modules')
]
},
resolve: {
modules: [
path.join(__dirname, 'node_modules')
]
}
};
I encountered this error in a TypeScript project. In my webpack.config.js file I was only resolving TypeScript files i.e.
resolve: {
extensions: [".ts"],
}
However I noticed that the node_module which was causing the error:
Field 'browser' doesn't contain a valid alias configuration
did not have any ".ts" files (which is understandable as the module has been converted to vanilla JS. Doh!).
So to fix the issue I updated the resolve declaration to:
resolve: {
extensions: [".ts", ".js"],
}
I had the same issue, but mine was because of wrong casing in path:
// Wrong - uppercase C in /pathCoordinate/
./path/pathCoordinate/pathCoordinateForm.component
// Correct - lowercase c in /pathcoordinate/
./path/pathcoordinate/pathCoordinateForm.component
Add this to your package.json:
"browser": {
"[module-name]": false
},
Changed my entry to
entry: path.resolve(__dirname, './src/js/index.js'),
and it worked.
This also occurs when the webpack.config.js is simply missing (dockerignore 🤦‍♂️)
In my case it was a package that was installed as a dependency in package.json with a relative path like this:
"dependencies": {
...
"phoenix_html": "file:../deps/phoenix_html"
},
and imported in js/app.js with import "phoenix_html"
This had worked but after an update of node, npm, etc... it failed with the above error-message.
Changing the import line to import "../../deps/phoenix_html" fixed it.
My case was rather embarrassing: I added a typescript binding for a JS library without adding the library itself.
So if you do:
npm install --save #types/lucene
Don't forget to do:
npm install --save lucene
Kinda obvious, but I just totally forgot and that cost me quite some time.
In my case, to the very end of the webpack.config.js, where I should exports the config, there was a typo: export(should be exports), which led to failure with loading webpack.config.js at all.
const path = require('path');
const config = {
mode: 'development',
entry: "./lib/components/Index.js",
output: {
path: path.resolve(__dirname, 'public'),
filename: 'bundle.js'
},
module: {
rules: [
{
test: /\.js$/,
loader: 'babel-loader',
exclude: path.resolve(__dirname, "node_modules")
}
]
}
}
// pay attention to "export!s!" here
module.exports = config;
I had aliases into tsconfig.json:
{
"compilerOptions": {
"paths": {
"#store/*": ["./src/store/*"]
}
},
}
So I solved this issue by adding aliases to webpack.config also:
module.exports = {
//...
resolve: {
alias: {
'#store': path.resolve(__dirname, '../src/store'),
},
},
};
I got same problem and fixed with adding file extension.
// Old:
import RadioInput from './components/RadioInput'
// New:
import RadioInput from './components/RadioInput.vue'
Also, if you still want to use without extensions, you can add this webpack config: (Thanx for #matthew-herbst for the info)
module.exports = {
//...
resolve: {
extensions: ['.js', '.json', '.wasm'], // Add your extensions here.
},
};
For anyone building an ionic app and trying to upload it. Make sure you added at least one platform to the app. Otherwise you will get this error.
In my experience, this error was as a result of improper naming of aliases in Webpack.
In that I had an alias named redux and webpack tried looking for the redux that comes with the redux package in my alias path.
To fix this, I had to rename the alias to something different like Redux.
In my case, it was due to a broken symlink when trying to npm link a custom angular library to consuming app. After running npm link #authoring/canvas
"#authoring/canvas": "path/to/ui-authoring-canvas/dist"
It appear everything was OK but the module still couldn't be found:
When I corrected the import statement to something that the editor could find Link:
import {CirclePackComponent} from '#authoring/canvas/lib/circle-pack/circle-pack.component';
I received this which is mention in the overflow thread:
To fix this I had to:
cd /usr/local/lib/node_modules/packageName
cd ..
rm -rf packageName
In the root directory of the library, run:
a) rm -rf dist
b) npm run build
c) cd dist
d) npm link
In the consuming app, update the package.json with:
"packageName": "file:/path/to/local/node_module/packageName""
In the root directory of the consuming app run npm link packageName
In my case (lolz),
I was importing a local package (that I was developing, and building with rollup) via NPM/Yarn link, into another package I was developing. The imported package was a load of React components, and was configured to have a peerDependency of react and react-dom.
The consuming package was being built with Webpack and obviously wasn't correctly feeding the installed react and react-dom libraries into my local dependency as it was compiling it.
I adjusted my webpack configuration to indicate it should alias those peer dependencies to the correct dependencies in the consuming package:
/* ... */
resolve: {
extensions: [/* make sure you have them all correct here, as per other answers */],
alias: {
react: path.resolve('./node_modules/react'),
'react-dom': path.resolve('./node_modules/react-dom')
}
},
/* ... */
Obviously you need to import path in the webpack.config.js file in order to use the methods seen above.
A more detailed explanation can be found in this article
My case was similar to #witheng's answer.
At some point, I noticed some casing error in some file names in my development environment. For example the file name was
type.ts
and I renamed it to
Type.ts
In my Mac dev environment this didn't register as a change in git so this change didn't go to source control.
In the Linux-based build machine where the filenames are case-sensitive it wasn't able to find the file with different casing.
To avoid issues like this in the future, I ran this command in the repo:
git config core.ignorecase false
In my case, I imported library files like:
import { MyFile } from "my-library/public-api";
After I removed the public-api from the import everything worked fine:
import { MyFile } from "my-library";
MyFile is exported in the public-api file in the library.
In my case,
I have mistakenly removed a library ("mini-create-react-context") from package.json. I added that back, and did yarn install and build the app and it start working properly. So please take a look at your package.json file once.
In my case I had accidentally imported this package while trying to use process.env:
import * as process from 'process';
Removing it fixed the problem.
For everyone with Ionic:
Updating to the latest #ionic/app-scripts version gave a better error message.
npm install #ionic/app-scripts#latest --save-dev
It was a wrong path for styleUrls in a component to a non-existing file.
Strangely it gave no error in development.
In my situation, I did not have an export at the bottom of my webpack.config.js file. Simply adding
export default Config;
solved it.
In my case, it is due to a case-sensitivity typo in import path. For example,
Should be:
import Dashboard from './Dashboard/dashboard';
Instead of:
import Dashboard from './Dashboard/Dashboard';
In my case I was using invalid templateUrl.By correcting it problem solved.
#Component({
selector: 'app-edit-feather-object',
templateUrl: ''
})
I am using single-spa, and encountered this issue with the error
Module not found: Error: Can't resolve '/builds/**/**/src\main.single-spa.ts' in /builds/**/**'
I eventually figured out that in angular.json build options "main" was set to src\\main.single-spa.ts. Changing it to src/main.single-spa.ts fixed it.
Had the same issue with angular was importing
import { Injectable } from "#angular/core/core";
changed it to
import { Injectable } from "#angular/core";
I was getting this error when running a GitHub action. The issue was because I'd listed the package as a peer dependency instead of a dependency.
Since I'm using Rollup, the solution was to install the package both as a peer dependency and a dev dependency, and use rollup-plugin-peer-deps-external to remove the dev dependency from the final build.
For me the issue was, I was importing
.ts files into .js files
changing them to ts as well solved the issue.
In my case, I had a mixture of enum and interface in the index.d.ts file.
I extracted enums into another file and the issue resolved.

Bundle ractive with ractive-load through Rollup

What is the correct way to import ractive and ractive-load to my rollup project? npm or github?
Currently I am using npm to install each one:
npm install --save-dev ractivejs/ractive
And
npm install --save-dev ractivejs/ractive-load
And I'm using rollup-plugin-commonjs with rollup-plugin-node-resolve to corretly bundle them (rollup.config.js in the end of the question):
import Ractive from 'ractive';
import load from 'ractive-load';
...
But it seems that ractive-load also imports other modules in its code, causing this error:
Error parsing /home/.../node_modules/rcu/src/make.js: 'import' and 'export' may only appear at the top level (2:0) in /home/.../node_modules/rcu/src/make.js
How can I correctly use Rollup and which are the right sources for this case (npm or github)?
Here is my rollup.config.js:
import commonjs from 'rollup-plugin-commonjs';
import nodeResolve from 'rollup-plugin-node-resolve';
export default {
entry: 'src/main.js',
plugins: [
nodeResolve({
jsnext: true,
main: true,
browser: true,
}),
commonjs({
sourceMap: false
}),
// uglify()
],
format: 'iife',
moduleName: 'Altiva',
dest: 'altiva.js'
};
ractive-load is intended to "read" link tags in the browser and then do AJAX requests for the component file, then it uses a library called rcu to convert the component files into usable javascript components.
What you need is a utility (that uses rcu or does equivalent work) to turn your component files into javascript files that you can run during build process then hand-off to rollup. Fortunately, it looks like there is a rollup plugin rollup-plugin-ractive designed to do just that:
rollup({
entry: 'src/main.js',
plugins: [
ractive({
// By default, all .html files are compiled
extensions: [ '.html', '.ract' ],
// You can restrict which files are compiled
// using `include` and `exclude`
include: 'src/components/**.html'
})
]
}).then(...)
There's also list of some of the available loaders here, among them are "plain vanilla js" variants as well.

Durandal.js optimizer not working (empty main-built.js)

I'm trying to get Durandal.js optimizer working on my test project, but it seems to generate nothing to main-built.js. I use the following command from node.js command prompt, in durandal/amd folder:
optimizer.exe --verbose true
Result is
Using default base configuration.
Configuring for deploy with almond (custom).
{
"name": "durandal/amd/almond-custom",
"inlineText": true,
"stubModules": [
"durandal/amd/text"
],
"paths": {
"text": "durandal/amd/text"
},
"baseUrl": "C:\\Users\\Tommi Gustafsson\\Documents\\Visual Studio 2012\\Projects\\DurandalTests\\DurandalTest1\\TestApp",
"mainConfigFile": "C:\\Users\\Tommi Gustafsson\\Documents\\Visual Studio 2012\\Projects\\DurandalTests\\DurandalTest1\\TestApp\\main.js",
"include": [
"main-built",
"main",
"bindings/tinymce-binding",
"durandal/app",
"durandal/composition",
"durandal/events",
"durandal/http",
"text!durandal/messageBox.html",
"durandal/messageBox",
"durandal/modalDialog",
"durandal/system",
"durandal/viewEngine",
"durandal/viewLocator",
"durandal/viewModel",
"durandal/viewModelBinder",
"durandal/widget",
"durandal/plugins/router",
"durandal/transitions/entrance",
"raphael-amd/eve.0.3.4",
"raphael-amd/raphael.2.1.0.amd",
"raphael-amd/raphael.2.1.0.core",
"raphael-amd/raphael.2.1.0.svg",
"raphael-amd/raphael.2.1.0.vml",
"viewmodels/flickr",
"viewmodels/modal1",
"viewmodels/myPage",
"viewmodels/shell",
"viewmodels/welcome",
"text!views/detail.html",
"text!views/flickr.html",
"text!views/modal1.html",
"text!views/myPage.html",
"text!views/shell.html",
"text!views/welcome.html"
],
"exclude": [],
"keepBuildDir": true,
"optimize": "uglify2",
"out": "C:\\Users\\Tommi Gustafsson\\Documents\\Visual Studio 2012\\Projects\\DurandalTests\\DurandalTest1\\TestApp\\main-built.js",
"pragmas": {
"build": true
},
"wrap": true,
"insertRequire": [
"main"
]
}
Deleting old output file.
Tracing dependencies for: durandal/amd/almond-custom
Then, when I check main-built.js, it is empty. Can anyone help me what is the problem? I have several AMD modules in the test project, including Raphael.js AMD modules.
My requirejs configuration looks like this:
requirejs.config({
paths: {
'text': 'durandal/amd/text',
'eve': './raphael-amd/eve.0.3.4',
'raphael.core': './raphael-amd/raphael.2.1.0.core',
'raphael.svg': './raphael-amd/raphael.2.1.0.svg',
'raphael.vml': './raphael-amd/raphael.2.1.0.vml',
'raphael': './raphael-amd/raphael.2.1.0.amd',
'tinymce': "../Scripts/tinymce/jquery.tinymce.min"
}
});
In the same amd folder, where optimizer is stored, try running node r.js -o app.build.js. I've seen r.js sometimes choke about some dependencies, which resolves without problem when loading via require.js. For whatever reason the error messages won't show up when using optimizer --verbose. Typically the error message provides enough information to see where this occurs and if you've to update require.contig.paths or a specific define dependency.