Total Pageviews

Wednesday, 3 December 2025

搭建基于nextjs的静态博客程序nbt



首先fork此项目https://github.com/pixegami/nextjs-blog-tutorial,我fork后的项目地址是https://github.com/briteming/nbt ,
然后访问https://github.com/briteming/nbt/tree/main/posts,新建源帖wp-ce.md,内容为

---
title: 稀奇古怪的中国经济
subtitle: 这是一篇文章
date: "2025-12-03"
---

(北京时间2008年7月04日 来稿) 正如俗话所说...

( 详见https://github.com/briteming/nbt/blob/main/posts/wp-ce.md?plain=1)

 然后访问vercel.com/new ,导入项目https://github.com/briteming/nbt,点击deploy按钮,等待部署完成,部署完成后,我得到网址https://nbt-eta.vercel.app/

 新建源帖后,博客网站2分钟内就会更新。

 项目地址:

https://github.com/pixegami/nextjs-blog-tutorial

 https://github.com/briteming/nbt

演示博客:https://nbt-eta.vercel.app/

p.s:  为了让发表的帖子按时间顺序排列, 请参照此文https://briteming.blogspot.com/2025/11/nextjshbnt.html的末尾的做法。

-------------------------

类似的, 基于nextjs的静态博客程序ntmb

 https://github.com/briteming/ntmb
https://github.com/briteming/ntmb/tree/main/posts
https://ntmb.vercel.app/

-------------------------------

 类似的, 基于nextjs的静态博客程序:next-netlify-blog-starter

  https://github.com/briteming/next-netlify-blog-starter
https://next-netlify-blog-starter-six.vercel.app/

Tuesday, 2 December 2025

搭建基于nextjs的静态博客程序nmbe(支持分页)

 

首先fork此项目https://github.com/alexchantastic/next-mdx-blog-example,我fork后的项目地址是https://github.com/briteming/nmbe ,
然后访问https://github.com/briteming/nmbe/tree/main/src/app/(posts)/,点击“add file",在出现的框里面,输入文件夹名称test/. 在test的右边又会出现一个框,在此框里,输入page.mdx ,然后在下面的大框里,输入:
 export const metadata = {
  title: "测试1",
  publishDate: "2025-12-01T22:48:00Z",
  categories: ["misc1", "misc2", "misc3"],
};

# 测试1

这是测试。

看看如何?

( 详见https://github.com/briteming/nmbe/blob/main/src/app/(posts)/test/page.mdx?plain=1)

 然后访问vercel.com/new ,导入项目https://github.com/briteming/nmbe,点击deploy按钮,等待部署完成,部署完成后,我得到网址https://nmbe-4rco.vercel.app/

 新建源帖后,博客网站2分钟内就会更新。

 项目地址:

https://github.com/alexchantastic/next-mdx-blog-example

 https://github.com/briteming/nmbe

演示博客:https://nmbe-4rco.vercel.app/ (支持分页)


探清水河

 

Sunday, 30 November 2025

搭建基于nextjs的静态博客程序ekmy


首先fork此项目https://github.com/ekomenyong/ekomenyong.com,我fork后的项目地址是https://github.com/briteming/ekmy/ ,
然后访问https://github.com/briteming/ekmy/tree/main/src/content,新建源帖test.mdx,内容为

---
title: 测试
publishedAt: "2025-11-30T17:42:00"
summary: 这是一篇文章 
category: misc
---

这是测试。

看看如何?

( 详见https://github.com/briteming/ekmy/blob/main/src/content/test.mdx?plain=1)

 然后访问vercel.com/new ,导入项目https://github.com/briteming/ekmy,点击deploy按钮,等待部署完成,部署完成后,我得到网址https://ekmy.vercel.app

 新建源帖后,博客网站2分钟内就会更新。

 项目地址:

https://github.com/ekomenyong/ekomenyong.com

 https://github.com/briteming/ekmy

演示博客:https://ekmy.vercel.app/

 https://ekmy.vercel.app/insights

 

NDoc - JavaScript documentation generator

 https://nodeca.github.io/ndoc/

NDoc is an inline comment parser and JavaScript documentation generator written in Node.JS. This project was inspired by PDoc. It tries to keep compatibility, but has some differences:

  • NDoc is primarily a CLI tool, so you don't need to code your documentor, although it can be easily used as library.
  • Clarified EBNF syntax. Definitions now MUST be separated with an empty line from the following comments.
  • Added options for deprecated tag: you can set versions, when tag was deprecated and when method/property will be removed.
  • Added new tags: read-only, internal, chainable
  • Events support.

How to Install

We suppose that you already have Node and npm installed. If not - try nvm.

npm install -g ndoc

Usage

usage: ndoc [-h] [-v] [--exclude PATTERN] [-o PATH] [--use PLUGIN]
            [--alias MAPPING] [-r RENDERER] [--link-format FORMAT]
            [-t TEMPLATE] [--show-all] [--package PACKAGE] [--index FILE]
            [--gh-ribbon URL] [--broken-links ACTION] [--noenv]
            PATH[PATH ...]

Positional arguments:
  PATH                            Source files location

Optional arguments:
  -h, --help                      Show this help message and exit.
  -v, --version                   Show program's version number and exit.
  --exclude PATTERN               Glob patterns of filenames to exclude (you
                                  can use wildcards: ?, *, **).
  -o PATH, --output PATH          Resulting file(s) location.
  --use PLUGIN                    Load custom plugin.
  --alias MAPPING                 Registers extensions alias. For example
                                  `cc:js` will register `cc` extension as an
                                  alias of `js`
  -r RENDERER, --render RENDERER  Documentation renderer (html, json). More
                                  can be added by custom plugins.
  --link-format FORMAT            View sources link (no links by default)
                                  format. You can use `{file}` and `{line}`
                                  and any of `{package.*}` variables for
                                  interpolation.
  -t TEMPLATE, --title TEMPLATE   Documentation title template. You can use
                                  any of `{package.*}` variables for
                                  interpolation. DEFAULT: `{package.name}
                                  {package.version} API documentation`
  --show-all                      By default `internal` methods/properties
                                  are not shown. This trigger makes ndoc show
                                  all methods/properties
  --package PACKAGE               Read specified package.json FILE. When not
                                  specified, read ./package.json if such file
                                  exists.
  --index FILE                    Index file (with introduction text), e.g.
                                  README.md file.
  --gh-ribbon URL                 Add "Fork me on GitHub" ribbon with given
                                  URL. You can use any of `{package.*}`
                                  variables for interpolation.
  --broken-links ACTION           What to do if broken link occurred (show,
                                  hide, throw). DEFAULT: `show`.
  --noenv                         Ignore .ndocrc

Syntax

NDoc Syntax. It is similar to PDoc one, with some extensions (see start of this doc for details).

For developers

You can generate prototype documentation for test:

make test

Then open ./tests/prototype-doc/index.html

from https://github.com/nodeca/ndoc 

搭建基于nextjs的静态博客程序hbnt


首先fork此项目https://github.com/hswolff/blog-with-nextjs-and-tailwind,我fork后的项目地址是https://github.com/briteming/hbnt ,
然后访问https://github.com/briteming/hbnt/tree/main/_content,新建源帖test.md,内容为

---
title: 测试
date: 2025-11-29
---

这是测试。

看看如何?

( 详见https://github.com/briteming/hbnt/blob/main/_content/test.md?plain=1)

 然后访问vercel.com/new ,导入项目https://github.com/briteming/hbnt,点击deploy按钮,等待部署完成,部署完成后,我得到网址https://hbnt.vercel.app/

 新建源帖后,博客网站2分钟内就会更新。

 项目地址:

https://github.com/hswolff/blog-with-nextjs-and-tailwind

 https://github.com/briteming/hbnt

演示博客:https://hbnt.vercel.app/

p.s:  为了让发表的帖子按时间顺序排列,可以这样做:

我仔细观察了 https://hbnt.vercel.app/里面的帖子的排列规律,是按字母顺序abcd...,然后按数字12345...,从页面的上部往下排列的,我发表的第1个帖子的源帖文件是test.md, 第2个帖子的源帖文件是test2.md,那么第2个帖子就会排在第1个帖子的下面。把之前发表的 ce.md删除,重新发表源帖tesu-ce.md; 因为u排在t的后面,所以源帖tesu-ce.md对应的帖子tesu-ce就会排在

 test2.md所对应的帖子test2的下面。

 把之前发表的fh.md删除,重新发表源帖tesu-fh.md; 因为f排在c的后面,所以源帖tesu-fh.md对应的帖子tesu-fh就会排在 tesu-ce.md所对应的帖子tesu-ce的下面.

不过最近发表的帖子一律在页面的底部。 

相关帖子: https://briteming.blogspot.com/2025/11/nextjssnrb.html (这个程序有同样的问题,我用同样的方法解决了)

从Vercel构建失败,谈 Git大小写敏感性问题:一个容易被忽视的跨平台陷阱


本地构建一切正常,但一到 Vercel 就报错?这可能是 Git 大小写敏感性在作祟。本文将分享一个真实的故障排查案例,帮助你避免这个隐蔽的跨平台兼容性问题。

问题背景:诡异的构建失败

最近在部署一个 React 项目到 Vercel 时,遇到了一个令人困惑的问题:

# 本地构建(成功)
pnpm run build
# ✅ 一切正常

# Vercel 构建(失败)
22:32:28.979 src/api/Article.ts(27,43): error TS2307: 
Cannot find module './HttpClient' or its corresponding type declarations.

奇怪的是,相同的代码、相同的依赖、相同的构建命令,在本地能够完美构建,但在 Vercel 上却失败了。

问题根源:大小写敏感性的差异

经过排查,发现问题出在文件命名上:

  • 实际文件名: httpClient.ts(首字母小写)
  • 导入语句: import HttpClient from './HttpClient';(首字母大写)

这个差异在不同操作系统环境下表现不同:

操作系统差异

环境 大小写敏感性 行为
Windows 不敏感 ./HttpClient./httpClient 都能找到文件
macOS 通常不敏感 同上
Linux (Vercel) 敏感 必须精确匹配 ./HttpClient

Git 的配置陷阱

问题的深层原因在于 Git 的配置:

# 检查 Git 大小写配置
git config core.ignorecase
# 返回: true

core.ignorecase=true 时,Git 不会区分文件名的大小写,这就导致了:

  1. 在 Windows/Mac 上开发时,一切正常
  2. 文件被提交为 httpClient.ts(小写)
  3. 但在 Linux 构建环境中,导入语句找不到对应的文件

解决方案:三步修复法

第一步:诊断问题

# 查看实际文件名
find . -name "*httpclient*" -type f
# 输出: ./src/api/httpClient.ts

# 查看 Git 记录的文件名
git ls-files | grep -i httpclient
# 输出: src/api/httpClient.ts

第二步:修复文件名

# 临时启用大小写敏感
git config core.ignorecase false

# 重命名文件(两步法避免冲突)
git mv src/api/httpClient.ts src/api/HttpClient.temp.ts
git mv src/api/HttpClient.temp.ts src/api/HttpClient.ts

# 提交修复
git commit -m "fix: correct HttpClient filename case sensitivity"
git push origin feat/reactpresss-config-v2

第三步:验证修复

# 在 GitHub 上确认文件名已更正
# 等待 Vercel 重新部署
# 构建应该成功通过

预防措施:建立防护网

1. 项目级配置

在项目中添加 .gitconfig 文件:

[core]
    ignorecase = false

2. ESLint 规则检查

配置 ESLint 检查文件名规范:

// .eslintrc.js
module.exports = {
  rules: {
    'unicorn/filename-case': [
      'error',
      {
        cases: {
          camelCase: true,    // 工具函数:camelCase
          pascalCase: true    // 类/组件:PascalCase
        }
      }
    ]
  }
};

3. CI/CD 流水线检查

在 GitHub Actions 中添加检查:

# .github/workflows/check-filenames.yml
name: Check Filename Case
on: [push, pull_request]

jobs:
  check-case:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Check filename consistency
        run: |
          for file in $(find src -name "*.ts" -o -name "*.tsx"); do
            filename=$(basename "$file" .ts | basename "$file" .tsx)
            if [[ $filename =~ [A-Z] ]]; then
              echo "✓ $filename uses PascalCase"
            else
              echo "⚠ $filename - consider using PascalCase for components/classes"
            fi
          done

4. 预提交钩子

使用 Husky 在提交前检查:

#!/bin/bash
# .husky/pre-commit
find src -name "*.ts" -o -name "*.tsx" | while read file; do
    base=$(basename "$file")
    if [[ $base =~ ^[a-z] ]] && [[ $base =~ \.(ts|tsx)$ ]]; then
        echo "警告: 建议类文件使用 PascalCase: $file"
    fi
done

深入理解:为什么会有这种差异?

历史原因

  • Windows: 源于 DOS,设计初衷是用户友好,不区分大小写
  • Linux: 源于 UNIX,强调精确和一致性,区分大小写
  • macOS: 基于 UNIX,但默认文件系统 HFS+/APFS 通常不区分大小写

Git 的设计选择

Git 为了跨平台兼容性,默认采用 core.ignorecase=true,这在实际开发中带来了便利,但也埋下了隐患。

最佳实践总结

  1. 统一命名规范
  • 类文件使用 PascalCase: HttpClient.ts
  • 工具函数使用 camelCase: formatDate.ts
  • 配置文件使用 kebab-case: app-config.ts
  1. 团队协作约定
  • 新成员入职时强调文件名规范
  • 代码审查时注意文件名大小写
  • 使用工具自动化检查
  1. 跨平台开发策略
  • 主要开发环境尽量与生产环境一致(推荐使用 Linux 容器)
  • 定期在 CI/CD 环境中测试构建
  • 建立快速反馈机制

结语

这个看似简单的"大小写"问题,实际上涉及操作系统设计、Git 工作原理、团队协作规范等多个层面。在跨平台开发日益普遍的今天,我们需要更加重视这类环境差异导致的问题。

记住:在本地能运行只是第一步,在生产环境能运行才是真正的完成

希望通过这个案例,你能避免类似的陷阱,建立更健壮的开发工作流。