Complete noob in react, this is day 2 of my learning. but basically:
tiny-relative-date to the app.import relativeDate from 'tiny-relative-date';npm run build and then it says it failed, but the app still works in the browser.output:
Garrett Morris@DESKTOP-U5VCBFV MINGW64 /e/blog
$ npm run build
> [email protected] build E:\blog
> react-scripts build
Creating an optimized production build...
Failed to compile.
Failed to minify the code from this file:
./node_modules/tiny-relative-date/src/factory.js:1
Read more here: http://bit.ly/2tRViJ9
npm ERR! Windows_NT 10.0.16299
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "build"
npm ERR! node v6.9.1
npm ERR! npm v3.10.8
npm ERR! code ELIFECYCLE
npm ERR! [email protected] build: `react-scripts build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build script 'react-scripts build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the blog package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! react-scripts build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs blog
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls blog
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! E:\blog\npm-debug.log
start and build are separate; try a different library! https://date-fns.org/v1.29.0/docs/distanceInWordsToNow
(and read the link provided in the error for reasoning)
@Timer I'm not going to try a different library; The library i'm using is fine and most importantly it is quite small. The error message appears to be a false alarm; the app its self is still compiled to the build directory...
Are you sure the whole (& functioning) application is present in the build directory?
The library you are using is not fine, as it ships uncompiled code and points to it under the src/ folder (via the module tag in package.json).
It's doubtful that the app would work if you serve it from the build folder -- is this what you're saying?
@Timer here is what it exported from that package:
/* 109 */
/***/ (function(module, __webpack_exports__, __webpack_require__) {
"use strict";
/* harmony export (immutable) */ __webpack_exports__["a"] = relativeDateFactory;
const calculateDelta = (now, date) => Math.round(Math.abs(now - date) / 1000)
function relativeDateFactory (translations) {
return function relativeDate (date, now = new Date()) {
if (!(date instanceof Date)) {
date = new Date(date)
}
let delta = null
const minute = 60
const hour = minute * 60
const day = hour * 24
const week = day * 7
const month = day * 30
const year = day * 365
delta = calculateDelta(now, date)
if (delta > day && delta < week) {
date = new Date(date.getFullYear(), date.getMonth(), date.getDate(), 0, 0, 0)
delta = calculateDelta(now, date)
}
const translate = (translatePhrase, timeValue) => {
let key
if (translatePhrase === 'justNow') {
key = translatePhrase
} else if (now >= date) {
key = `${translatePhrase}Ago`
} else {
key = `${translatePhrase}FromNow`
}
const translation = translations[key]
if (typeof translation === 'function') {
return translation(timeValue)
}
return translation.replace('{{time}}', timeValue)
}
switch (false) {
case !(delta < 30):
return translate('justNow')
case !(delta < minute):
return translate('seconds', delta)
case !(delta < 2 * minute):
return translate('aMinute')
case !(delta < hour):
return translate('minutes', Math.floor(delta / minute))
case Math.floor(delta / hour) !== 1:
return translate('anHour')
case !(delta < day):
return translate('hours', Math.floor(delta / hour))
case !(delta < day * 2):
return translate('aDay')
case !(delta < week):
return translate('days', Math.floor(delta / day))
case Math.floor(delta / week) !== 1:
return translate('aWeek')
case !(delta < month):
return translate('weeks', Math.floor(delta / week))
case Math.floor(delta / month) !== 1:
return translate('aMonth')
case !(delta < year):
return translate('months', Math.floor(delta / month))
case Math.floor(delta / year) !== 1:
return translate('aYear')
default:
return translate('overAYear')
}
}
}
/***/ }),
/* 110 */
/***/ (function(module, exports) {
module.exports = {
justNow: "just now",
secondsAgo: "{{time}} seconds ago",
aMinuteAgo: "a minute ago",
minutesAgo: "{{time}} minutes ago",
anHourAgo: "an hour ago",
hoursAgo: "{{time}} hours ago",
aDayAgo: "yesterday",
daysAgo: "{{time}} days ago",
aWeekAgo: "a week ago",
weeksAgo: "{{time}} weeks ago",
aMonthAgo: "a month ago",
monthsAgo: "{{time}} months ago",
aYearAgo: "a year ago",
yearsAgo: "{{time}} years ago",
overAYearAgo: "over a year ago",
secondsFromNow: "{{time}} seconds from now",
aMinuteFromNow: "a minute from now",
minutesFromNow: "{{time}} minutes from now",
anHourFromNow: "an hour from now",
hoursFromNow: "{{time}} hours from now",
aDayFromNow: "tomorrow",
daysFromNow: "{{time}} days from now",
aWeekFromNow: "a week from now",
weeksFromNow: "{{time}} weeks from now",
aMonthFromNow: "a month from now",
monthsFromNow: "{{time}} months from now",
aYearFromNow: "a year from now",
yearsFromNow: "{{time}} years from now",
overAYearFromNow: "over a year from now"
}
And herein lies the problem; this is the ES6 feature the bit.ly link mentions is not supported:
const calculateDelta = (now, date) => Math.round(Math.abs(now - date) / 1000)
@Timer thank you i take up with package owner. sadly, i was under impression create-react-app would do the transpiling. sadly i guess not.
Apologies for commenting on such an old issue, but as the author of the package mentioned (tiny-relative-date) I thought I'd chime in. Webpack is importing the module path of this package, which is using well-supported ES2015 features such as arrow functions. Things might have changed in create-react-app in the months since this issue was opened but it seems like if the minifier bundled with create-react-app can't handle ES2015 features, then it might be preferable to configure Webpack to import packages from their main path, which are often CommonJS/ES5, instead of module.
@wildlyinaccurate the module entry is only supposed to contain ES-Modules; all other language features must still be compiled to the lowest target support platform of your package.
Including new language features not present in your main files is considered extremely poor practice (as-in, main and module should be identical except for ES Modules; no disparity between arrow functions, etc).
http://2ality.com/2017/04/setting-up-multi-platform-packages.html#overview
http://2ality.com/2017/04/transpiling-dependencies-babel.html#the-status-quo
What you are doing belongs in the esnext field, not the module field.
I was more referring to the fact that ES modules (or rather the import and export statements) are defined in the same spec as arrow functions. I would be loath to include features from ES>2015 in the module entry, but I find it baffling that any tooling or workflow would cherry-pick support for ES modules without supporting any of the other features defined in the ES2015 spec.