I did something wrong
"tsc" could not be found
Can you tell me what CPU are you running it on? Or is it a VM ?
Intel(R) Atom(TM) x5-Z8300 CPU @ 1.44GHz 1.44 GHz
You might find it interesting to know that these days I am a professional software engineer and I'm proud to say that HFS and its template scripting is how I got my (unconventional) start.
I don't interested in Node for some reasons. But I wonder if there will be a template engine, just like the old classic HFS2.
... So it successfully reads it but then cannot rewrite it. ...
<link href="https://fonts.googleapis.com/icon?family=Material+Icons+Outlined" rel="stylesheet" id="iconsFile">
By blocking the request, the list loads blazing fast.Next I'll test my template (https://rejetto.com/forum/index.php?topic=11754.msg1066673#msg1066673).
Need to learn typescript first (modified).
thanks for reporting the quick*.js problem. I reuploaded the release so that it's fixed.
Can you tell me why you removed the icons file ?
For those that need HEAVY customization, totally replacing the "frontend" folder will be an option.
Anyway, that should be the last option. Let's try to focus on customizing the default frontend without touching it.
Tell me what you would like to customize exactly.
Argument `sse` is directly from url query, so it's string. Even when we pass `?sse=0` it is still true.
So may convert it to number along with `offset` and `limit`.
@NaitLee have a look at the new plugin example, it may be what you need for your project.
Refer to the README file for details
plugin error importing test.js RangeError: Maximum call stack size exceeded
To reproduce, a single "require" to HFS native module in a valid plugin can trigger this.i don't know if you saw the new template, but is very similar to the one of hfs 2.4 . Is that simple enough? if negative, could you tell me what you would like to see removed?Not simple enough for file server. Because most users don't need to see server management menu.
can you tell me what is "server management menu" that you want to hide? i still fail to see
Also, I think standard template needs to go on a weight-reduction diet on scale of 3x~5x smaller and easier to work on.
Howabout a new thread for HFS3x user interface contest? Fun!
...It's not even a problem of "it's hard to edit it" because you almost CAN'T do it. You are not supposed to, because it's against the kind of technology used there. That's why I'm trying to do the job through plugins.I think that the plugins method in HFS3 is a great improvement.
Editing the template was a big plus of HFS2, but also a huge problem...with consequences on functionality...
import process_1 from 'process';
import path_1 from 'path';
// Workaround for my workspace, which is symlinked to plugin directory.
const NODE_PATH = process_1.cwd();
export function absRequire(path: string): any {
return require(path_1.join(NODE_PATH, path));
}
This is used to solve many things, with absolute cwd.import { absRequire } from './absRequire';
const frontEndApis_1: HFSFrontEndApis = absRequire('frontEndApis').frontEndApis;
const config_1: HFSConfig = absRequire('./config');
These are before hfs 0.6. They work just well.this.data = data = { ...data }
var traditTpl = function(ctx) { template.serve(ctx); return true; }
traditTpl.prototype.middleware = function(ctx) { template.serve(ctx); return true; }
// ...
module.exports = traditTpl;
I just think it maybe useful, so wrote this by casual. And hfs 0.6 really want a "middleware" attribure.The ISP here seldomly allows me (and other people) to access GitHub, whether I can access HFS repository is by luck.
If possible please mirror the repo to somewhere like GitLab (https://docs.gitlab.com/ee/user/project/repository/mirror/#repository-mirroring), then ones here can have another way...
I see the directory structure changed.
But it made me confused: should I access HFS libs by simply importing the original files?
This is used to solve many things, with absolute cwd.
While we are exposing some apis in another way (like the const api = exports.api = {}), which means we'd better just use it.
But in theory it's always not enough, and if there's something missing, I will directly import HFS libs then use stuffs inside, without nothing bad.
So the suggestion is, simply make HFS libs themselves useable in a standard way,
EDIT: "including" the built-in stuffs to a central lib is also an option, and this can keep interfaces stable (not suddenly changed in the future)
PS. I personally feel the exports.api with setTimeout uncomfortable. So I don't want to use it :(
While I can understand changes to plugin, this "cloning" may not as good as think. It's better to consider the "prototype" in JavaScript.
var traditTpl = function(ctx) { template.serve(ctx); return true; }
traditTpl.prototype.middleware = function(ctx) { template.serve(ctx); return true; }
// ...
module.exports = traditTpl;
I just think it maybe useful, so wrote this by casual. And hfs 0.6 really want a "middleware" attribure.
But this didn't work -- the object cloning doesn't clone the prototype.
const { getConfig } = require('../../src/config')
console.log('ciao', getConfig('port'))
exports.api = {}
exports.init = function() {
const { getConfig } = require(exports.api.srcDir + '/config')
console.log('ciao', getConfig('port'))
}
:root .theme-dark a { color: #fff9;}22 vulnerabilities (3 low, 18 moderate, 1 high)
# npm audit report
follow-redirects <1.14.7
Severity: high
Exposure of sensitive information in follow-redirects - https://github.com/advisories/GHSA-74fj-2j2h-c42q
fix available via `npm audit fix`
node_modules/follow-redirects
1 high severity vulnerability
To address all issues, run:
npm audit fix
I don't interested in Node for some reasons. But I wonder if there will be a template engine, just like the old classic HFS2.